OBJECT MODELLING USING UML UML is a modelling language used for creating models. Not a system design or development methodology. Used to document result of object-oriented analysis and design. Independent of any specific design methodology

OBJECT MODELLING USING UML Provides set of notations(e.g. rectangles, lines etc.) to create a visual model of the system. UML has its own syntax and semantics.

UNIFIED MODELLING LANGUAGE (UML) Origin In late 1980s and early 1990s different software development houses were using different notations to document object oriented designs. Developed in early 1990s to standardize the large number of object-oriented modelling notations

UML UML was developed to standardize the large number of object-oriented modeling notations that existed and were used extensively in the early 1990s. Based Principally on OMT [Rumbaugh 1991] Booch’s methodology[Booch 1991] OOSE [Jacobson 1992] Odell’s methodology[Odell 1992] Shlaer and Mellor [Shlaer 1992]

UML OMT UML Booch Methodology OOSE Different object modelling techniques in UML

UML As a Standard Adopted by Object Management Group (OMG) in 1997 OMG an association of industries Promote extensive set of notations and techniques Used outside software development, example car manufacturing

WHY UML IS REQUIRED? Required to capture only important aspects UML a graphical modelling tool, easy to understand and construct Helps in managing complexity

UML DIAGRAMS Construct Nine diagrams to capture five different views of a system Provide different perspectives of the software system Diagrams can be refined to get the actual implementation of the system

UML DIAGRAMS Five Views of a system User’s view Structural view Behavioral view Implementation view Environmental view

UML DIAGRAMS Diagrams and views in UML Behavioural View User’s View Use Case Diagram Structural View Class Diagram Object Diagram Implementation View Component Diagram Environmental View Deployment Diagram Behavioural View Sequence Diagram Collaboration Diagram - State-chart Diagram - Activity Diagram Diagrams and views in UML

USER’S VIEW Defines the functionalities (facilities) made available by the system to its users. Black-box view of the system - where the internal structure, the dynamic behaviour of different system components, the implementation etc. are not visible. Considered as the central view and all other views are expected to conform to this view.

STRUCTURAL VIEW Defines the kinds of objects important to the understanding of the working of a system and to its implementation. Captures the relationships among the objects. Called the static model, since the structure of a system does not change with time.

BEHAVIORAL VIEW Captures how objects interact with each other to realize the system behavior. Captures the time-dependent (dynamic) behavior of the system.

IMPLEMENTATION VIEW Captures the important components of the system and their dependencies.

ENVIRONMENTAL VIEW Models how the different components are implemented on different pieces of hardware.

NO ARE ALL VIEWS REQUIRED? Use case model, class diagram and one of the interaction diagram for a simple system State chart diagram in case of many state changes Deployment diagram in case of large number of hardware components

USE CASE MODEL Consists of set of “use cases” An important analysis and design artifact Other models must confirm to this model Not really an object-oriented model Represents a functional or process model

USE CASES Different ways in which system can be used by the users Corresponds to the high-level requirements Represents transaction between the user and the system Define behavior without revealing internal structure of system Set of related scenarios tied together by a common goal

USE CASES Use cases are independent of each other Implicit dependencies may exist

EXAMPLE OF USE CASES For library information system issue-book Query-book Return-book Create-member Add-book, etc.

REPRESENTATION OF USE CASES Represented by use case diagram Use case is represented by ellipse System boundary is represented by rectangle Users are represented by stick person icon (actor) Communication relationship between actor and use case by line External system by stereotype

EXAMPLE OF USE CASES TIC-TAC-TOE Use case model Tic-tac-toe game Play Move Player

WHY DEVELOP USE CASE DIAGRAM? Serves as requirements specification Users identification helps in implementing security mechanism through login system Another use in preparing the documents (e.g. user’s manual)

FACTORING USE CASES Complex use cases need to be factored into simpler use cases Represent common behavior across different use cases Three ways of factoring Generalization Includes Extends

GENERALIZATION Generalization works the same way with use cases as it does with classes. The child use case inherits the behavior and meaning of the parent use case. The base and the derived use cases are separate use cases and should have separate text descriptions.

FACTORING USING GENERALIZATION Pay membership fee Pay through library pay card Pay through credit card Use case generalization

INCLUDES Involves one use case including the behavior of another use case in its sequence of events and actions. The includes relationship occurs when a chunk of behavior that is similar across a number of use cases. As shown in fig., the includes relationship is represented using a predefined stereotype <<include>>.

FACTORING USING INCLUDES Base use case Use case inclusion Common use case <<include>> Issue Book Update selected book Get user selection Check for reservation Renew Book <<include>> Paralleling model

EXTENDS It allows you to show optional system behavior. This relationship among use cases is also predefined as a stereotype <<extends>> as shown in fig.. Similar to generalization but the extending use case can add additional behavior only at an extension point only when certain conditions are satisfied. The extends relationship is normally used to capture alternate paths or scenarios.

FACTORING USING EXTENDS Base use case Use case extension Common <<extends>>

ORGANIZATION OF USE CASES When the use cases are factored, they are organized hierarchically. The high-level use cases are refined into a set of smaller and more refined use cases as shown in fig. Top-level use cases are super-ordinate to the refined use cases.

ORGANIZATION OF USE CASES The refined use cases are sub-ordinate to the top-level use cases. Only the complex use cases should be decomposed and organized in a hierarchy. This level is also referred to as the context diagram.

HIERARCHICAL ORGANIZATION OF USE CASES External users use case 3.1 use case 3. 2 use case 3.3 Subsystems use case 1 use case 2 use case 3 Method Hierarchical organization of use cases

CLASS DIAGRAM Describes static structure of a system. Shows how a system is structured rather than how it behaves. Main constituents are classes and their relationships: Generalization Aggregation Association Various kinds of dependencies

CLASS Entities with common features, i.e. attributes and operations Classes are represented as solid outline rectangle with compartments Classes have a mandatory name compartment where the name is written centered in boldface.

CLASS The class name is usually written using mixed case convention and begins with an uppercase. The class names are usually chosen to be singular nouns. Attribute and operation compartment are optional for reuse purpose

ATTRIBUTES An attribute is a property of a class. Represents kind of data that an object might contain. Type of the attribute is written by appending a colon and the type name after the attribute name. First letter of a attribute is a small letter. Example : bookName : String

OPERATION Implementation of a service that can be requested from any object. An object’s data or state can be changed by invoking an operation of the object. A class may have any number of operations or no operation at all. First letter of an operation name is a small letter. Abstract operations are written in italics.

OPERATION The parameters of an operation may be - ‘in’, ‘out’ or ‘inout’. Example: issueBook(in bookName):Boolean

EXAMPLE OF CLASS DIAGRAM LibraryMember Member Name Membership Number Address Phone Number E-Mail Address Membership Admission Date Membership Expiry Date Books Issued issueBook( ); findPendingBooks( ); findOverdueBooks( ); returnBook( ); findMembershipDetails( ); LibraryMember LibraryMember Member Name Membership Number Address Phone Number E-Mail Address Membership Admission Date Membership Expiry Date Books Issued Different representations of the LibraryMember class

ASSOCIATION RELATIONSHIP Enable objects to communicate with each other Describes a connection between classes. The association relation between two objects is called object connection or link. Usually binary relation but more classes can be involved

ASSOCIATION RELATIONSHIP Class can have relationship with itself (recursive association) Association between two classes is represented by drawing a straight line The name of the association is written along side the association line. Arrowhead used along with name indicates reading direction of association Multiplicity indicates how many instances of one class are associated with each other.

ASSOCIATION RELATIONSHIP Association between two classes Library Member Book 1 * borrowed by

AGGREGATION RELATIONSHIP Involved classes are not only associated to each other but also represent a whole-part relationship Example: a book register is an aggregation of book object. Represented by diamond symbol at the composite end

AGGREGATION RELATIONSHIP Cannot be reflexive(i.e. recursive) - an object cannot contain objects of the same class as itself. Not symmetric - Two classes A and B cannot contain instances of each other. It can be transitive - Consist of an arbitrary number of levels.

AGGREGATION RELATIONSHIP Representation of aggregation Document Line 1 * Paragraph

COMPOSITIONRELATIONSHIP Composition is a stricter form of aggregation. Parts are existence-dependent on the whole. When the whole is created, the parts are created and when the whole is destroyed, the parts are destroyed. Represented as a filled diamond drawn at the composite-end.

COMPOSITION RELATIONSHIP Order 1 * Item Representation of composition

INHERITANCE RELATIONSHIP Inheritance describes ‘is a’ / ‘is a kind of’ relationship between classes . Inheritance is defined statically. It can not be changed at run-time.

INHERITANCE RELATIONSHIP

OBJECT DIAGRAM Shows the snapshot of the objects in a system. Shows instances of classes rather than classes themselves, often called instance diagram. Undergo continuous change as execution proceeds. Useful to explain the working of a system.

OBJECT DIAGRAM Different representations of the LibraryMember object Mritunjay B10028 C-108, Laksmikant Hall 1119 Mrituj@cse 25-02-04 25-03-06 NIL IssueBook( ); findPendingBooks( ); findOverdueBooks( ); returnBook( ); findMembershipDetails( ); LibraryMember Mritunjay B10028 C-108, Laksmikant Hall 1119 Mrituj@cse 25-02-04 25-03-06 NIL LibraryMember Different representations of the LibraryMember object

INTERACTION DIAGRAM Models that describes how groups of objects interact among themselves. Each interaction diagram realizes behaviour of a single use case

INTERACTION DIAGRAM Two kinds: Sequence & Collaboration Two diagrams are equivalent in the sense that any one diagram can be derived automatically from the other but portrays different perspective These diagram play a very important role in the design process

SEQUENCE DIAGRAM Shows interaction among objects as two- dimensional chart The chart is read from top to bottom. Objects are shown as boxes at top of chart. Inside the box the name of the object is written with a colon separating it from the name of the class.

SEQUENCE DIAGRAM Both the name of the object and the class are underlined The objects appearing at the top signify object already existed when the use case execution was initiated. If object created during execution then shown at appropriate place.

SEQUENCE DIAGRAM Objects existence are shown as dashed lines (object’s lifeline) Objects activeness, shown as rectangle on lifeline called activation symbol. Messages are shown on arrows

SEQUENCE DIAGRAM Message labelled with message name Message can be labelled with control information Two types of control information: condition ([]) & an iteration (*)

EXAMPLE OF SEQUENCE DIAGRAM The sequence diagram for the book renewal use case for the Library Automation Software is shown in fig.

EXAMPLE OF SEQUENCE DIAGRAM :Library Boundary Book Renewal Controller Register :Book Member renewBook displayBorrowing selectBooks [reserved] apology confirm find MemberBorrowing bookSelected * find update updateMemberBorrowing Sequence Diagram for the renew book use case

COLLABORATION DIAGRAM Shows both structural and behavioural aspects The structural aspect consists of objects and the links existing between them. Objects are collaborator, shown as boxes The behavioral aspect is described by the set of messages exchanged among the different collaborators

COLLABORATION DIAGRAM Link between objects shown as a solid line. Message is shown as a labelled arrow placed near the link Messages are prefixed with sequence numbers to show relative sequencing

EXAMPLE OF COLLABORATION DIAGRAM :Library Boundary Book Renewal Controller Register :Book Member 1: renewBook 3: display Borrowing 4: selectBooks [reserved] 8: apology 12: confirm 2: findMemberBorrowing 5: book Selected 6: * find 9: update 7: apology 10: confirm updateMemberBorrowing Collaboration Diagram for the renew book use case

ACTIVITY DIAGRAM New concept, possibly based on event diagram of Odell [1992] Represent processing activity, may not correspond to methods of classes Activity is a state with an internal action and one/many outgoing transition

ACTIVITY DIAGRAM Normally employed in business process modelling Carried out during requirement analysis and specification Can be used to develop interaction diagrams

ACTIVITY DIAGRAM Can represent parallel activity and synchronization aspects Important feature of activity diagram - Swim lanes - enable to group activities based on who is performing them Example: academic department vs. hostel

EXAMPLE OF ACTIVITY DIAGRAM The student admission process in IIT is shown as an activity diagram. This shows the part played by different components of the Institute in the admission procedure. After the fees are received at the account section, parallel activities start at the hostel office, hospital, and the Department. After all these activities complete (this synchronization is represented as a horizontal line), the identity card can be issued to a student by the Academic section.

EXAMPLE OF ACTIVITY DIAGRAM check student records Academic Section receive fees allot room hostel create hospital record conduct medical examination register in course Accounts Section Hostel Office Hospital Department issue identity card Activity diagram for student admission procedure at IIT

STATE CHART DIAGRAM Based on the work of David Harel [1990] Model how the state of an object changes in its lifetime Describe how the behavior of the object changes across several use case execution. Based on finite state machine (FSM) formalism

WHY STATE CHART DIAGRAM State chart avoids problem of state explosion as in FSM State explosion - The number of states becomes too many and the model too complex. Hierarchical model of a system and represents composite state (nested)

STATE CHART DIAGRAM Elements of state chart diagram Initial State: Filled circle Final State: Filled circle inside larger circle State: Rectangle with rounded corners Transitions: Arrow between states, also boolean logic condition (guard). The syntax for the label of the transition is: event[guard]/action.

EXAMPLE OF STATE CHART DIAGRAM An example of state chart for the order object of the Trade House Automation software is shown in fig.

EXAMPLE OF STATE CHART DIAGRAM Unprocessed Order Fulfilled Pending Accepted Rejected order received [reject] checked [accept] checked [some items not available] processed [all items available] newsupply [some items available] processed / deliver Example: State chart diagram for an order object

COMPONENT DIAGRAM Piece of a software that can be independently purchased, upgraded and integrated into existing software. Represent the physical structure of implementation

COMPONENT DIAGRAM Used for two purposes: Organizing source code Specify dependencies among different components.

DEPLOYMENT DIAGRAM Shows the environmental view of the system. Shows how the software system will be physically deployed in the hardware environment. Diagram models the run time architecture of an application.