UML Unified Markup Language

1. UMLUnified Markup Language Ziya Karakaya Atılım University, Computer Engineering ziya@atilim.edu.tr

2. DEFINITION • Unified Markup 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 Jacabson, but its reach is wider than that. • UML went through a standardization process with the OMG (Object Management Grouop) and is now an OMG standard.

3. 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.

4. 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

5. 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.

6. 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.

7. 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.

8. 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.

9. FUNDAMENTAL UML • Models and Views • Core Diagrams • Fundamental Elements

10. 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.

12. 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.

13. 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 system’s class structure.

14. 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.

15. VIEWS • 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.

16. USE CASE VIEW • This view documents the system from the customer’s 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.

17. Design VIEW • This view documents the system from designer’sand architect’s perspective. • Diagrams most commonin this view are class and interaction diagrams(either sequence or collaboration), as wellas package diagrams illustrating the packagestructure of our Java application.

18. Development VIEW • This view documents the components that thesystem is composed of. • This view typically containscomponent diagrams. • Except for the mostcomplex Javaapplications, this view isoptional.

19. Process • This view documents the processes and threadsthat compose our application. • These processesand threads typically are captured on class diagramsusing an active class. • Because of theadvanced nature of active classes, coupled withthe volume of use, active classes are beyond thescope of this discussion.

20. Physical VIEW • This view documents the system topology. • Deployment diagrams that compose this viewillustrate the physical nodes and devices thatmake up the application, as well as theconnectionsthat exist between them.

21. 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.

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

23. Behavioral diagrams • Behavioral diagrams depict the dynamic aspects of our system.They are most useful for specifying the collaborations among elements that satisfythe behavior of our system’s requirements. • Five diagrams that fall into this category are; • Use case • Activity • State • Sequence • Collaboration • 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 usecases. • State diagrams, on the other hand, are used to illustrate complextransitionsin behavior for a single class.

24. Use case diagrams • Use case diagrams are centered around the business processes that ourapplication must support. • Most simply, use case diagrams enable us tostructureour entire application around the core processes that it must support. • Doing soenables us to use these use cases to drive the remainder of the modeling anddevelopment effort. • Shows a set of actors and use cases, and the relationshipsbetween them. • Use case diagrams contributeto effective model organization, as well asmodeling the core behaviors of a system.

25. Activity Diagrams • Models the flow of activity between processes. • These diagrams are most useful in detailing usecase behavior. • An activity diagram doesn’t showcollaboration among objects.

26. State Diagrams • Illustrates internal state-related behavior of anobject. • Transitions between states help identify,and validate, complex behavior. • A class can haveat most a single state diagram.

27. Sequence Diagrams • Semantically equivalent to a collaboration diagram. • sequence diagram is a type of interactiondiagram that describes time ordering of messagessent between objects. • Almost in all software development activity, this diagram is used.

28. Collaboration Diagrams • A type of interaction diagram that describes theorganizational layout of the objects that sendand receive messages. • Semantically equivalent toa sequence diagram. • It uses class diagrams layout, and can be used to make more cohesive and less coupled classes.

29. STRUCTURAL DIAGRAMS • Diagrams in this category are focused on specifying the static aspects of our system. • Of these four diagrams, theclass diagram is most often used. • when transitioning to the UML, mostorganizations tend to use class diagrams first because they are excellent mechanismsfor communication among developers, as well as tools that can be usedfor problem solving. • There are two forms of class diagrams. • The first is the most commonlyunderstood and consists of the classes that compose our system and of thestructure among these classes. • Unfortunately, the second is not often used butis of equal importance and can be most effective in helping developers understandour system from a high level. • A type of class diagram, called a packagediagram, often represents the Java packages and the dependencies betweenthem that our application consists of.

30. Class Diagrams • Illustrates a set of classes, packages, and relationshipsdetailing a particular aspect of a system. • This diagram is likely the most commonone used in modeling.

31. Object Diagrams • Provides a snapshot of the system illustrating thestatic relationships that exist between objects. • Object diagrams depict the structural relationship thatexists 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 ofbehavior. • Many people have found that object diagrams are most useful in fleshingout the instance relationships among objects, which in turn can help verifyour class diagrams. • Beyond this, object diagrams are not often used.

32. Component Diagrams • Addresses the static relationships existingbetween the deployable softwarecomponents. • Examples of components may be .exe, .dll, .ocx,jar files, and/or Enterprise JavaBeans. • Component diagrams might beused to show the software components within our application. • Componentsaren’t equivalent to classes.

33. Deployment Diagrams • Describes the physical topology of a system. • Typically includes various processing nodes,realized in the form of a device (for example, aprinter or modem) or a processor (forexample, aserver). • Deployment diagrams are most useful when we have a complex configurationenvironment. • If ourapplication is to be deployed to multiple servers, across locations, a deploymentdiagram might be useful.