UML UNIFIED MODELING LANGUAGE Hoang Huu Hanh, PhD [email protected] based on online courses and...

UML UNIFIED MODELING LANGUAGE Hoang Huu Hanh, PhD [email protected] based on online courses and presentations

DEFINITION Unified Modeling Language is the successor to the wave of Object- Oriented Analysis and Design methods that appear in the late `80s and early `90s. Most directly unifies the methods of Booch, Rumbaugh (OMT), and Jacobson, but its reach is wider than that. UML went through a standardization process with the OMG (Object Management Group) and is now an OMG standard. 2Introduction to UML

UML History 3Introduction to UML

WHAT IT IS UML is a modeling language, not a method Most methods consist, at least in principle, of both a modeling language and a process. Modelling Language is the (mainly graphical) notation that methods use to express designs. Process is their advice on what steps to take in doing a design. Modeling Language is the most important part of the method, which is the key part of communication. 4Introduction to UML

WHY USE UML Helps Analysis and Design Used for communication Use the advantages of OO Documentation As stated in The Unified Modeling Language User Guide; UML is a language for: Visualizing Specifying Constructing Documenting 5Introduction to UML

Visualizing It makes it easier to understand and work through problem Since it is a formal language, it enables other developers familiar with the language to more easily interpret our drawings. 6Introduction to UML

Specifying We must communicate our software system using some common, precise, and unambiguous communication mechanism. Again the formal nature of the UML facilitates this specification quite nicely. 7Introduction to UML

Constructing We know that the UML is a formal language with its own set of syntactical rules. Because of this formality, we can create tools that interpret our models. They can map the elements to a programming language, such as Java, C++. Many tools such as Rational Rose, supports this forward engineering. In fact this is one of the advantages of using a formal modeling tool. 8Introduction to UML

Documenting The models we create are just one of the articats produced throughout the development lifecycle. Using the UML in a consistent fashion produces a set of documentation that can serve as a blueprint of our system. 9Introduction to UML

USAGES Define the boundaries of a system & its major functions use cases and actors Illustrate use cases interaction diagrams Define the static structure of a system class diagrams Model the behavior of objects state transition diagrams Document the physical implementation architecture component & deployment diagrams Provide for growth stereotypes 10Introduction to UML

FUNDAMENTAL UML Models and Views Core Diagrams Fundamental Elements 11Introduction to UML

12Introduction to UML

Models and Views UML is more than disjointed diagrams Turn attention to an illustration of the UML from three different perspectives Further insight into these divisions enables us to realize one of the greatest benefits of modeling, which is creating different views of our software system. 13Introduction to UML

Core Elements 14Introduction to UML

Core Elements (contd) An extension mechanism useful for specifying structural elements. 15Introduction to UML

Fundamental Elements These are the elements of which diagrams are composed Understanding the intent of each element enables us to create precise diagrams, because each of them has unambiguous meaning. 16Introduction to UML

DIAGRAMS Individual diagrams contribute more to the specification of a software system. They are composition of many of the fundamental elements. Are mechanism that developers use to communicate and solve problems in the complex aspects of the system. The most common diagram is the Class Diagram, which describe the structural relationships that exist among the classes, can guide developers in understanding our software systems class structure. 17Introduction to UML

VIEWS As we become more proficient in modeling, we begin to realize that using a combination of diagrams to communicate is most effective. We may need to combine class diagram with a diagram whose intent is to give systems dynamics. By combining these called views. View is a depiction of our system from a particular perspective. By making different views, we can represent our system from different perspectives. 18Introduction to UML

VIEWS (contd) There are five main views, Use case Design Development Process Physical They must be consistent with each other, because all of them are representing the same system. Can be used to validate each other. 19Introduction to UML

USE CASE VIEW This view documents the system from the customers perspective. Terminology used in this view should be domain specific. Depending on the technical nature of our audience, we should avoid obscure technical terms. Diagrams most common in this view are the use case diagrams and, less common, activity diagrams. Organizations transitioning to the UML may wish to work only with use case diagrams early and experiment with activity diagrams over time. 20Introduction to UML

Design VIEW This view documents the system from designers and architects perspective. Diagrams most common in this view are class and interaction diagrams (either sequence or collaboration), as well as package diagrams illustrating the package structure of our Java application. 21Introduction to UML

Development VIEW This view documents the components that the system is composed of. This view typically contains component diagrams. Except for the most complex Java applications, this view is optional. 22Introduction to UML

Process VIEW This view documents the processes and threads that compose our application. These processes and threads typically are captured on class diagrams using an active class. Because of the advanced nature of active classes, coupled with the volume of use, active classes are beyond the scope of this discussion. 23Introduction to UML

Physical VIEW This view documents the system topology. Deployment diagrams that compose this view illustrate the physical nodes and devices that make up the application, as well as the connections that exist between them. 24Introduction to UML

VIEWS (cont.) We are not limited with the listed views. If there is something that architecturally important, for example security, then we may create a new view (ex: security view) into the system from that perspective. 25Introduction to UML

Modeling Elements Structural elements class, interface, collaboration, use case, active class, component, node Behavioral elements interaction, state machine Grouping elements package, subsystem Other elements note 26Introduction to UML

Diagrams - The foundation of UML Use Case Diagrams Requirements Activity Diagrams Generally what, not who - good to detect parallelism Interaction Diagrams Collaboration/Communication Diagrams (object centered) Sequence Diagrams (timeline) Static Structure Diagrams Objects/Classes/Packages Statechart Diagrams States of objects with interesting lifecycles Implementation Diagrams Component Diagrams Deployment Diagrams 27Introduction to UML

DIAGRAMS As weve seen, we can combine diagrams that form models and that can serve as views into our system. If an advantage in modeling is to combine diagrams to form views into our system, then it only makes sense that each diagram has a different focus on what it communicates. Each falls into one of two categories: behavioral, and structural. Most commonly used are use case, sequence, and class diagrams. 28Introduction to UML

Behavioral diagrams Behavioral diagrams depict the dynamic aspects of our system.They are most useful for specifying the collaborations among elements that satisfy the behavior of our systems requirements. Five diagrams that fall into this category are; Use case Activity State Sequence Collaboration (Communication) Mostly used are use case, sequence, and collaboration. Activity and state diagrams are used on an as-needed basis. Activity diagrams visually represent behaviors captured by use cases. State diagrams, on the other hand, are used to illustrate complex transitions in behavior for a single class. 29Introduction to UML

Core Relationships 30Introduction to UML

Core Relationships (contd) 31Introduction to UML

Relationships An association is a bi-directional connection between classes An association is shown as a line connecting the related classes An aggregation is a stronger form of relationship where the relationship is between a whole and its parts An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier A dependency is shown as a dashed line pointing from the client to the supplier 32Introduction to UML

Relationship Notation 1 - one and only one 4 - four and only 4 0..1 - zero or 1 5..10 - five to and including 10 0..* - zero or more 4..* - four or more 33Introduction to UML

Finding Relationships Relationships are discovered by examining interaction diagrams If two objects must talk there must be a pathway for communication 34 Registration Manager Math 101: Course 3: add student(joe) RegistrationManager Course Introduction to UML

Relationships 35 RegistrationForm RegistrationManager Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) name major location open() addStudent(StudentInfo) name tenureStatus ScheduleAlgorithm Introduction to UML

Associations 36

Association Ends Introduction to UML37

Relationship Notation 1 - one and only one 4 - four and only 4 0..1 - zero or 1 5..10 - five to and including 10 0..* - zero or more 4..* - four or more 38Introduction to UML

Ternary Associations Introduction to UML39

Composition Introduction to UML40

Composition (contd) Introduction to UML41

Generalization Introduction to UML42

Generalization Introduction to UML43

Dependencies Introduction to UML44

Dependencies Introduction to UML45

Derived Attributes and Associations Introduction to UML46

Links Introduction to UML47

Constraints and Comments Introduction to UML48

Actors An actor is someone or some thing that interacts with the system External Forces Human interaction Automated System 49 Keyboard Operator User Driver Traffic Control System > Introduction to UML

Use Cases A use case is a pattern of behavior the system exhibits Each use case is a sequence of related transactions performed by an actor and the system in a dialogue Details what the system must provide to the actor when the use cases is executed A flow of events document is created for each use case Written from an actor point of view Actors are examined to determine their how they interact with the system Break down into the most atomic actions possible Typical contents How the use case starts and ends Normal flow of events Alternate flow of events Exceptional flow of events 50Introduction to UML

Use case diagrams Use case diagrams are centered around the business processes that our application must support. Most simply, use case diagrams enable us to structure our entire application around the core processes that it must support. Doing so enables us to use these use cases to drive the remainder of the modeling and development effort. Shows a set of actors and use cases, and the relationships between them. Use case diagrams contribute to effective model organization, as well as modeling the core behaviors of a system. 51Introduction to UML

Use Case Diagram Captures system functionality as seen by users Built in early stages of development Purpose Specify the context of a system Capture the requirements of a system Validate a systems architecture Drive implementation and generate test cases Developed by analysts and domain experts 52Introduction to UML

Use Case Diagram Use case diagrams are created to visualize the relationships between actors and use cases 53 Passager Mechanic Driver Lost Luggage Ramp Maintenance Pay toll Customer Service Agent Introduction to UML

Use Case Diagram Captures system functionality as seen by users 54Introduction to UML

Collaboration Diagrams A type of interaction diagram that describes the organizational layout of the objects that send and receive messages. Semantically equivalent to a sequence diagram. It uses class diagrams layout, and can be used to make more cohesive and less coupled classes. 55Introduction to UML

Collaboration Diagram A collaboration diagram displays object interactions organized around objects and their links to one another 56 : Registrar course form : CourseForm theManager : CurriculumManager aCourse : Course 1: set course info 2: process 3: add course 4: new course Introduction to UML

Sequence Diagrams Semantically equivalent to a collaboration diagram. sequence diagram is a type of interaction diagram that describes time ordering of messages sent between objects. Almost in all software development activity, this diagram is used. 57Introduction to UML

Sequence Diagram A sequence diagram displays object interactions arranged in a time sequence 58 Passenger Counter Agent Ticket Gate Agent 1: Give Info 3: Answer 4: Print 6:Present 7: Board 9: Return 8: Overbook 2: Questions Plane 5: Safeguard Introduction to UML

The State of an Object A state transition diagram shows The life history of a given class The events that cause a transition from one state to another The actions that result from a state change State transition diagrams are created for objects with significant dynamic behavior 59Introduction to UML

State Transition Diagrams Illustrates internal state-related behavior of an object. Transitions between states help identify, and validate, complex behavior. A class can have at most a single state diagram. 60Introduction to UML

State Transition Diagram 61 Initialization Open entry: Register student exit: Increment count ClosedCanceled do: Initialize course do: Finalize course do: Notify registered students Add Student / Set count = 0 Add student[ count < 10 ] [ count = 10 ] Cancel Introduction to UML

Activity Diagrams Models the flow of activity between processes. These diagrams are most useful in detailing use case behavior. An activity diagram doesnt show collaboration among objects. 62Introduction to UML

STRUCTURAL DIAGRAMS Diagrams in this category are focused on specifying the static aspects of our system. Of these four diagrams, the class diagram is most often used. when transitioning to the UML, most organizations tend to use class diagrams first because they are excellent mechanisms for communication among developers, as well as tools that can be used for problem solving. There are two forms of class diagrams. The first is the most commonly understood and consists of the classes that compose our system and of the structure among these classes. Unfortunately, the second is not often used but is of equal importance and can be most effective in helping developers understand our system from a high level. A type of class diagram, called a package diagram, often represents the Java packages and the dependencies between them that our application consists of. 63Introduction to UML

Class Diagrams Illustrates a set of classes, packages, and relationships detailing a particular aspect of a system. This diagram is likely the most common one used in modeling. 64Introduction to UML

Class Diagrams A class diagram shows the existence of classes and their relationships in the logical view of a system UML modeling elements in class diagrams Classes and their structure and behavior Association, aggregation, dependency, and inheritance relationships Multiplicity and navigation indicators Role names Attributes The structure of a class is represented by its attributes Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge Operations The behavior of a class is represented by its operations Operations may be found by examining interaction diagrams 65Introduction to UML

Class Diagram Captures the vocabulary of a system 66Introduction to UML

Object Diagrams Provides a snapshot of the system illustrating the static relationships that exist between objects. Object diagrams depict the structural relationship that exists among the objects within our running application at a given point in time. When we think of the runtime version of our system, we typically think of behavior. Many people have found that object diagrams are most useful in fleshing out the instance relationships among objects, which in turn can help verify our class diagrams. Beyond this, object diagrams are not often used. 67Introduction to UML

Relationships Relationships provide a pathway for communication between objects Sequence and/or collaboration diagrams are examined to determine what links between objects need to exist to accomplish the behavior -- if two objects need to talk there must be a link between them Three types of relationships are: Association Aggregation Dependency 68Introduction to UML

Multiplicity and Navigation Multiplicity defines how many objects participate in a relationships Multiplicity is the number of instances of one class related to ONE instance of the other class For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship Although associations and aggregations are bi- directional by default, it is often desirable to restrict navigation to one direction If navigation is restricted, an arrowhead is added to indicate the direction of the navigation 69Introduction to UML

Multiplicity and Navigation 70 RegistrationForm RegistrationManager Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location open() addStudent(StudentInfo) tenureStatus ScheduleAlgorithm 1 0..* 1 1 1..* 4 3..10 0..4 1 Introduction to UML

Inheritance Inheritance is a relationships between a superclass and its subclasses There are two ways to find inheritance: Generalization Specialization Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy 71Introduction to UML

Inheritance 72 RegistrationForm RegistrationManager Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location open() addStudent(StudentInfo) tenureStatus ScheduleAlgorithm name RegistrationUser Introduction to UML

The Physical World Component diagrams illustrate the organizations and dependencies among software components A component may be A source code component A run time components or An executable component 73Introduction to UML

Component Diagrams Addresses the static relationships existing between the deployable software components. Examples of components may be.exe,.dll,.ocx, jar files, and/or Enterprise JavaBeans. Component diagrams might be used to show the software components within our application. Components arent equivalent to classes. 74Introduction to UML

Component Diagram Captures the physical structure of the implementation 75Introduction to UML

Deploying the System The deployment diagram shows the configuration of run-time processing elements and the software processes living on them The deployment diagram visualizes the distribution of components across the enterprise. 76Introduction to UML

Deployment Diagram Captures the topology of a systems hardware 77Introduction to UML

Extensibility Mechanisms Stereotype Tagged value Constraint 78Introduction to UML

Extending the UML Stereotypes can be used to extend the UML notational elements Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components Examples: Class stereotypes: boundary, control, entity, utility, exception Inheritance stereotypes: uses and extends Component stereotypes: subsystem 79Introduction to UML

Deployment Diagrams Describes the physical topology of a system. Typically includes various processing nodes, realized in the form of a device (for example, a printer or modem) or a processor (for example, a server). Deployment diagrams are most useful when we have a complex configuration environment. If our application is to be deployed to multiple servers, across locations, a deployment diagram might be useful. 80Introduction to UML

Q & A time to ask questions 81Introduction to UML

Thank you! take a break 82Introduction to UML

UML UNIFIED MODELING LANGUAGE Hoang Huu Hanh, PhD [email protected] based on online courses and...

Documents

Transcript of UML UNIFIED MODELING LANGUAGE Hoang Huu Hanh, PhD [email protected] based on online courses and...