Introduction to UML. Defining UML Modeling with UML Describing the Modeling Process Defining the Syntax of UML Clarifying with an Example OUTLINE. - презентация

1 Introduction to UML

2 Defining UML Modeling with UML Describing the Modeling Process Defining the Syntax of UML Clarifying with an Example OUTLINE

3 Unified Modeling Language is a standard language for writing software blueprints WHAT IS UML?

4 WHO DEVELOPED IT? Object Management Group Grady BoochJames Rumbaugh Ivar Jacobson

5 UML TOOLS Rational Rose - IBM ArgoUML – Tigris Visual Studio.NET - Microsoft

6 A model in the context of software development can be graphical, textual, mathematical, or program code-based. Models are very useful in documenting the design and analysis results. Graphical models are very popular because they are easy to understand and construct. UML is primarily a graphical modeling tool. What is modeling?

7 Need for a model An important reason behind constructing a model is that it helps manage complexity Example 1: Physician find the facts about the patient Normally when a patient goes for a general check-up, the Physician on looking at the previous history of the patient, will understand the situation much faster than if he has to go for a full investigation. The physician is trying to avoid the irrelevant data items so that he can come to the root cause as soon as possible. Example 2: Take an entity as BOOK. Let us try to find out the different characteristics of the same entity from the perspective of the viewer. Let us take 2 cases where the same entity BOOK can be viewed differently: 1. Library System In this case we will be focusing on Access Number, Book Name, Author Name 2. Shopkeeper In this case we will be focusing on Item Number, Item Name, Price, Quantity On Hand.

8 The following are some reasons for Software Complexity: – Numerous Business rules (Functional Requirements) – Non-Functional Requirements like Usability Performance Cost Reliability Distributed nature Portability – Complexity due to development process

9 Once models of a system have been constructed, these can be used for a variety of purposes during software development, including the following: Analysis Specification Code generation Design Visualize and understand the problem and the working of a system Testing, etc.

10 WHY MODEL? VisualizingSpecifying Constructing Documenting

11 Visual modeling (visualizing) A picture is worth a thousand words! - Uses standard graphical notations - Semi-formal -Captures Business Process from enterprise information systems to distributed Web-based applications and even to hard real time embedded systems Specifying building models that are: Precise, Unambiguous, Complete UML symbols are based on well-defined syntax and semantics. UML addresses the specification of all important analysis, design, and implementation decisions.

12 Constructing Models are related to OO programming languages. Round-trip engineering requires tool and human intervention to avoid information loss – Forward engineering direct mapping of a UML model into code. – Reverse engineering reconstruction of a UML model from an implementation. Documenting A Healthy software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include – Architecture, Requirements, Tests, Activities (Project planning, Release management)

13 UMLs STRENGTHS Which compels us to be: More Precise More Complete Less Ambiguous Its easy to read and if accepted would be a language that everyone understood

14 UMLs WEAKNESSES There is a big difference between: Compel and Ensures There is insufficient means for test and verification (For instance: there is no mean to specify relational tables)

15 What is an Object ? An object is an unique, identifiable, self-contained entity that contains attributes and behaviors. A software object is modeled after real world objects A software object is a representative of the real world object Can be viewed as a "black box" which receives and sends messages – Examples Car Telephone Pen etc Object Oriented Thinking

16

17 What is a Class ? A Class is a blue print used to create objects. Is a software template that defines the methods and variables to be included in a particular kind of Object. Examples : Animal, Human being, Automobiles, Bank Account, Customer Class Contains.. State (Member variables) The internal state of the object represented by values stored in member variables Variables defined inside a class form the State of the class Not exposed to external world Behavior (Member Methods) Behavior exhibited by the class to external world Functions defined inside the class form the behavior of the class Exposed to external world

18

19

20

21

22

23 Encapsulation (Data hiding) Process of hiding the members from outside the class Implemented using the concept of access specifiers public, private etc. Typically in a class State is private (not accessible externally) Behavior is public (accessible externally) By enforcing this restriction, Object oriented programming allows isolation of complexity in a manageable way

24

25 Mid 90's 50 different Object-Oriented Analysis and Design (OOAD) notations and methods Oct 95 Grady Booch and James Rumbaugh publish Unified Method 0.8 Fall 95Ivar Jacobson joined Rational June 96 Unified Modeling Language 0.9 Nov 97 UML 1.1 was adopted as industry standard by Object Management Group (OMG) June 98 First conference on UML (still a workshop) June 99 UML 1.3 (model interchange included) March 2003 UML 1.5 (Action Language included) 2005 UML 2.0 History of the UML

26 BUILDING BLOCKS of UML THINGS RELATINSHIPS DIAGRAMS

27 THINGS IN UML 4 things in UML 1.Structural Things: Focuses on STATIC part of system 2.Behavioral Things: Focuses on DYNAMIC part of system 3.Grouping Things: Focuses on PACKAGES & GROUPING of components 4.Annotational Things: Focuses on Explanatory part & Documentation part

28 Structural Things(classiffication) 1.Class 2.Interface 3.Collabaration 4.Usecase 5.Active class 6.Component 7.Node

29 Class: is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations. Interface Interface is a collection of operations that specify a service of a class or component. An interface therefore describes the externally visible behavior of that element. An interface might represent the complete behavior of a class or component or only a part of that behavior. An interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is typically attached to the class or component that realizes the interface

30 Collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Therefore, collaborations have structural, as well as behavioral, dimensions. A given class might participate in several collaborations. Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name Usecase Use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor Use case is used to structure the behavioral things in a model. A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name

31 Active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations Component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs

32 Node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube, usually including only its name Behavioral Things 2 classifications 1.Interaction 2.state machine Interaction Interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose An interaction involves a number of other elements, including messages, action sequences and links Graphically a message is rendered as a directed line, almost always including the name of its operation

33 State Machine State machine is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events State machine involves a number of other elements, including states, transitions, events and activities Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates Grouping Things:- 1.are the organizational parts of UML models. These are the boxes into which a model can be decomposed 2.There is one primary kind of grouping thing, namely, packages. Package:- A package is a general-purpose mechanism for organizing elements into groups. Structural things, behavioral things, and even other grouping things may be placed in a package Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents

34 Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe about any element in a model. A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment Relationships in the UML: There are four kinds of relationships in the UML: Dependency Association Generalization Realization Dependency:- Dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing Graphically a dependency is rendered as a dashed line, possibly directed, and occasionally including a label

35 Association is a structural relationship that describes a set of links, a link being a connection among objects. Graphically an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. Graphically a realization relationship is rendered as a cross between a generalization and a dependency relationship

36 Diagrams in the UML Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). In theory, a diagram may contain any combination of things and relationships. For this reason, the UML includes nine such diagrams: 1.Class diagram 2.Object diagram 3.Use case diagram 4.Sequence diagram 5.Collaboration diagram 6.Statechart diagram 7.Activity diagram 8.Component diagram 9.Deployment diagram Class diagram A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Class diagrams that include active classes address the static process view of a system. Object diagram Object diagrams represent static snapshots of instances of the things found in class diagrams These diagrams address the static design view or static process view of a system An object diagram shows a set of objects and their relationships

37 Use case diagram A use case diagram shows a set of use cases and actors and their relationships Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system. Interaction Diagrams Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams Interaction diagrams address the dynamic view of a system A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and transform it into the other Statechart diagram A statechart diagram shows a state machine, consisting of states, transitions, events, and activities Statechart diagrams address the dynamic view of a system They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object

38 Activity diagram An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system Activity diagrams address the dynamic view of a system They are especially important in modeling the function of a system and emphasize the flow of control among objects Component diagram A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system They are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations Deployment diagram A deployment diagram shows the configuration of run-time processing nodes and the components that live on them Deployment diagrams address the static deployment view of an architecture

39 Summary ThingsRelationships Diagrams Structural RealizationAnnotational Grouping Behavioral Generalization Association Dependency class Window size open() waiting state Business rules package Return copies notes dependencyassociation GeneralizationRealization

40 DIAGRAMS StaticDynamic Class Object Component Deployment Use Case Sequence Collaboration Statechart Activity

41 OCL OMG MDA

42 OCL: It is a sublanguage of UML. It is used to add constraints/business rules to models. Why OCL: In UML class diagrams were typically not refined enough to provide all the relevant aspects of a specification.We need to describe additional constraints about objetcs in the model. Such constraints are often defined in natural language. But the understanding of formal language require mathematical background. To avoid such complexity we go for OCL.

43 EXAMPLE

44 OCL can be used for: OCL can be used as a query language for extracting information. Used for specifying the stereotypes. Used to specify constraints on different operations. Used to specify pre and post conditions on operations.

45 OMG: It developments are CORBA,UML. In 1997 OMG has issued following specifications that are not CORBA based UML MOF(Meta Object Facility) XML Metadata Interchange(XMI)

46 Model-Driven Architecture The current state of affairs

47 What is MDA? OMG's standard for making software designs independent of implementation platforms. Can be based on other standards, such as UML, MOF, XMI. Allows for gradual refinement of designs towards implementation platforms.

48 How does MDA work? Start with a Platform- Independent Model (PIM) representing business functionality and behaviour, accurate by technology details. Platform- Independent Model A Detailed Model, stating Pre- and Post- Conditions in OCL, and Semantics in Action Language Some slides from OMG...

49 How does MDA work? Platform- Independent Model CORBA Model MDA tool applies a standard mapping to generate Platform- Specific Model (PSM) from the PIM. Code is partially automatic, partially hand- written. Java/EJB Model XML/SOAP Model Other Model Map a PIM to Many Middleware Technologies via OMG Standard Mappings Some slides from OMG...

50 How does MDA work? Some slides from OMG... Platform- Independent Model CORBA Model MDA Tool generates all or most of the implementation code for deployment technology selected by the developer. Java/EJB Model CORBA XML/SOAP Model Java/EJB XML/SOAP Other Other Model Map PSM to application interfaces, code, GUI descriptors, SQL queries, etc. Recent addition: Computation Independent Model (CIM) => Represents a domain model.

51 MDA Mapping PIM PSM Transformation

52 MDA Mapping An MDA mapping provides specifications for transformation of a PIM into a PSM for a particular platform. The platform model will determine the nature of the mapping. (MDA Guide V 1.0)

53 Model Type Mappings Maps PIM language types to PSM language types: –Metamodel Mappings: types in PIM and PSM are specified as MOF metamodels. Uses mapping rules/algorithms to map PIM type instances to PSM type instances. –Other Mappings: e.g. CORBA IDL.

54 Model Instance Mappings Transforms specific PIM model elements: –Marks: represents a PSM concept and is applied to a PIM element to indicate how it is to be transformed. Most mappings are a combination of type and instance mappings. Templates can be associated with a set of marks.

55 Example: CORBA OMG has defined a UML profile for CORBA => this serves as a CORBA platform model. Specific stereotypes in the PIM will be transformed to CORBA stereotypes.

56 Transformation Marking Transformation PIM PSM Marked PIM Marks MappingPlatform

57 Transformation Metamodel Transformation PIM PSM Transf. Specs PI Meta- model PS Meta- model Source language Target language Language used

58 Transformation Model Transformation PIM PSM Transf. Specs PI Types PS Types Source types Target types Subtypes of

59 Tools ArcStyler ARI – Kabira xUML, iUML, iCCG Codagen Tools Adaptive Framework CodigoXpress Headway ReView ObjectSpeak BridgePoint, DesignPoint OptimalJ – Compuware Eclipse Modeling Framework Netbeans AndroMDA MiddleGen xPetstore (in progress) CoCompose?...

60 MOF(META OBJECT FACILITY): It was created by OMG. It is an extensible model driven integration framework for defining, manipulating and integrating metadata and data in a platform independent manner. The MOF is intended to be a framework for developing new metamodels. The MOF models use a number of building block concepts. 1.Reflection: 2.Identity: 3.Extension:

61 XMI It is a model driven XML integration framework. This is used for defining XML data and objects XMI based standards are used for integrating tools, repositories and data warehouses. The main purpose behind XMI is to enable easy interchange of metadata.

62 CORBA Purpose and goals: Enable the building of plug and play component software environment Enable the development of portable, object oriented, interoperable code that is hardware, operating system, network, and programming language independent

63 How to meet goals? Interface Definition Language (IDL) Object Request Broker (ORB)

64 Interface Definition Language (IDL) Language Independence Defines Object Interfaces Hides underlying object implementation Language mappings exist for C, C++, Java, Cobol, Smalltalk, and Ada

65 IDL Compiler IDL Definitions IDL Compiler StubsSkeletons 1.Define objects using IDL 2.Run IDL file through IDL compiler 3.Compiler uses language mappings to generate programming language specific stubs and skeletons

66 CORBA IDL I D L ORB CC++COBOLAda Small talk More Client Side Object Implementation Side COBOLC Ada C++ Small talk More I D L ORB

67 ORB ? Implementation of CORBA specification Middleware product Conceptual Software Bus Hides location and implementation details about objects

68 Object Request Broker Application Interface Object Services Object Services Domain Interface Common Facilities

69 CORBA Introspection Client ORB DII IDL stubs ORB interface IDL skeleton DSI Object Adapter GIOP/IIOP ORB CORE Object Implementation

70 RUP 4+1 VIEW Architecture

71 The UML is largely process-independent, meaning that it is not tied to any particular software development life cycle. However, to get the most benefit from the UML, we should consider a process that is Use case driven Architecture-centric Iterative and incremental Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating the system's architecture, for testing, and for communicating among the stakeholders of the project. Architecture-centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. An iterative process is one that involves managing a stream of executable releases. An incremental process is one that involves the continuous integration of the system's architecture to produce these releases,with each new release embodying incremental improvements over the other.

72 This use case driven, architecture-centric, and iterative/incremental process can be broken into phases. A phase is the span of time between two major milestones of the process. There are four phases in the software development life cycle: inception, elaboration, construction, and transition.

73

74 Inception is the first phase of the process, when the seed idea for the development is brought up to the point of being at least internally sufficiently well-founded to warrant entering into the elaboration phase. Elaboration is the second phase of the process, when the product vision and its architecture are defined. In this phase, the system's requirements are articulated, prioritized, and baselined. A system's requirements may range from general vision statements to precise evaluation criteria, each specifying particular functional or nonfunctional behavior and each providing a basis for testing. Construction is the third phase of the process, when the software is brought from an executable architectural baseline to being ready to be transitioned to the user community. Here also, the system's requirements and especially its evaluation criteria are constantly reexamined against the business needs of the project, and resources are allocated as appropriate to actively attack risks to the project. Transition is the fourth phase of the process, when the software is turned into the hands of the user community. Rarely does the software development process end here, for even during this phase, the system is continuously improved, bugs are eradicated, and features that didn't make an earlier release are added.

75 Architecture A system's architecture is perhaps the most important artifact that can be used to manage these different viewpoints and so control the iterative and incremental development of a system throughout its life cycle. Architecture is the set of significant decisions about the organization of a software system Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic concerns.

76 Different diagrams of system for different people Process ViewDeployment View Logical View Use-Case View Implementation View End-user Functionality Programmers Software management Performance, scalability, throughput System integrators System topology, delivery, installation, communication System engineering Analysts/Designers Structure

77 Use case view The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. With the UML, the static aspects of this view are captured in use case diagrams The dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams. LogicalView The design view of a system encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users.

78 Process View The process view of a system encompasses the threads and processes that form the system's concurrency and synchronization mechanisms. This view primarily addresses the performance, scalability, and throughput of the system Implementation View The implementation view of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the system's releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system. Deployment View The deployment view of a system encompasses the nodes that form the system's hardware topology on which the system executes. This view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system.

79 UML Meta Model, Extensibility mechanisms like stereotypes Tagged values, constraints and profiles

80 UML META MODEL Is a UML class model that describes UML. CLASS PROPERTY OPERATION 0..1 * *

81 UML META MODEL DESIGN PRINCIPLES Modularity Layering Partitioning Extensibility Reuse MODULARITY: It refers to the ability to separate different objects, classes and piece of functionality into physically separate modules. Benefits are: Information hiding Loose coupling Strong cohesion

82 LAYERING 4 Tier layered model M3: the meta-meta model(MOF) M2:the meta model(CWM-Common Ware house Model) M1:the model(Classes) M0:the user level instances of M1 classes(Objects) PARTITIONING It is a mechanism employed in software design to reduce coupling between different constructs EXTENSIBILTY The UML can be extended using profiles. The J2EE and.NET platform can be easily modeled using profile extension.

83 REUSE The meta model design is reuse. All constructs from the UML meta model are actually instances of reused, Predefined constructs in the infrastructure Library.

84 EXTENSIBILITY MECHANISMS Stereotypes A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of building blocks similar to existing ones but specific to the problem.

85 Tagged Values Every thing in the UML has its own set of properties: classes have names, attributes, and operations; associations have names and two or more ends (each with its own properties); and so on. With stereotypes, you can add new things to the UML; with tagged values, you can add new properties. A tagged value is not the same as a class attribute. Rather, you can think of a tagged value as metadata because its value applies to the element itself, not its instances. A tagged value is an extension of the properties of a UML element, allowing you to create new information in that element's specification. Graphically, a tagged value is rendered as a string enclosed by brackets and placed below the name of another element. In its simplest form, a tagged value is rendered as a string enclosed by brackets and placed below the name of another element. That string includes a name (the tag), a separator (the symbol =), and a value (of the tag).

86

87 Constraints A constraint specifies conditions that must be held true for the model to be well-formed. A constraint is rendered as a string enclosed by brackets and placed near the associated element Graphically, a constraint is rendered as a string enclosed by brackets and placed near the associated element or connected to that element or elements by dependency relationships.

88 PROFILES It is an extension of package. The notation for profile is same as package