1. Unit I/UML/MCA/NIEVenkata Ratnam K1 Introducing the UML and UML Diagrams

2. Unit I/UML/MCA/NIEVenkata Ratnam K2 Why Model?  Modeling achieves four aims: Helps you to visualize a system as you want it to be. Permits you to specify the structure or behavior of a system. Gives you a template that guides you in constructing a system. Documents the decisions you have made.  You build models of complex systems because you cannot comprehend such a system in its entirety.  You build models to better understand the system you are developing. What Is a Model?  A model is “a complete description of a system from a particular perspective.” A model is a simplification of reality.

3. Unit I/UML/MCA/NIEVenkata Ratnam K3 Importance of Modeling Unified Modeling Language (UML)  used for both database and software modeling  version 1.1 was adopted in November 1997 by the Object  Management Group (OMG) as a standard language for object- oriented analysis and design  Initially based on a combination of the Booch, OMT (Object Modeling Technique) and OOSE (Object-Oriented Software Engineering) methods, UML was refined and extended by a consortium of several companies, and is undergoing minor revisions by the OMG Revision Task Force.  Ivar Jacobson is known as the father of Use Cases. Four Principles of Modeling The model you choose influences how the problem is attacked. Every model may be expressed at different levels of precision. The best models are connected to reality. No single model is sufficient.

4. Unit I/UML/MCA/NIEVenkata Ratnam K4 What is UML?  Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.  Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge.  It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools).  used for both database and software modeling

5. Unit I/UML/MCA/NIEVenkata Ratnam K5 Overview of the UML  The UML is a language for visualizing specifying constructing documenting the artifacts of a software-intensive system

6. Unit I/UML/MCA/NIEVenkata Ratnam K6 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.

7. Unit I/UML/MCA/NIEVenkata Ratnam K7 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 Architecture, Requirements, Tests, Activities (Project planning, Release management)

8. Unit I/UML/MCA/NIEVenkata Ratnam K8 Conceptual Model of the UML » To understand the UML, you need to form a conceptual model of the language, and this requires learning three major elements. Elements: 1. Basic building blocks 2. Rules 3. Common Mechanisms Basic Building Blocks of the UML The vocabulary of the UML encompasses three kinds of building blocks: » Things » Relationships » Diagrams

9. Unit I/UML/MCA/NIEVenkata Ratnam K9 Things in the UML  There are four kinds of things in the UML: 1. Structural — nouns of UML models. 2. Behavioral — dynamic (verbal) parts of UML models. 3. Grouping — organizational parts of UML models. 4. Annotational — explanatory parts of UML models.

10. Unit I/UML/MCA/NIEVenkata Ratnam K10 1.Structural Things  These are the Nouns and Static parts of the model.  These are representing conceptual or physical elements. There are seven kinds of structural things: 1. Class 2. Interface 3. Collaboration 4. Use Case 5. Active Class 6. Component 7. Node

11. Unit I/UML/MCA/NIEVenkata Ratnam K11 1.Class Is a description of set of objects that share the same attributes, operations methods, relationships and semantics. 2.Interface A collection of operations that specify a service (for a resource or an action) of a class or component. It describes the externally visible behavior of that element Window origin size open( ) close( ) move( ) Name Attributes Operations A Simple Class A Simple Interface Iname > IWindow open() close() name operations

12. Unit I/UML/MCA/NIEVenkata Ratnam K12 3.Collaboration – Define an interaction among two or more classes. – Define a society of roles and other elements. – Provide cooperative behavior. – Capture structural and behavioral dimensions. – UML uses ‘pattern” as a synonym (careful) 4.Use Case – A sequence of actions that produce an observable result for a specific actor. – A set of scenarios tied together by a common user goal. – Provides a structure for behavioral things. – Realized through a collaboration (usually realized by a set of actors and the system to be built). Name Behavior Place order

13. Unit I/UML/MCA/NIEVenkata Ratnam K13 5. Active Class – Special class whose objects own one or more processes or threads. – Can initiate control activity. 6. Component  Replaceable part of a system.  Components can be packaged logically.  Conforms to a set of interfaces.  Provides the realization of an interface.  Represents a physical module of code 7. Node  Element that exists at run time.  Represents a computational resource.  Generally has memory and processing power. Orderform.java Web Server Event Manager Thread time suspend() flush() Name attributes operations Heavy border

14. Unit I/UML/MCA/NIEVenkata Ratnam K14 2.Behavioral Things  These are Verbs of UML models.  These are Dynamic parts of UML models: “behavior over time and space”  Usually connected to structural things in UML. There are two kinds of Behavioral Things: 1.Interaction  Is a behavior of a set of objects comprising of a set of messages exchanges within a particular context to accomplish a specific purpose. 2.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. display Idle Waiting

15. Unit I/UML/MCA/NIEVenkata Ratnam K15 3.Grouping Things  These are the organizational parts of the UML models. There is one primary kind of group thing: 1.Packages - General purpose mechanism for organizing elements into groups. - Purely conceptual; only exists at development time. - Contains behavioral and structural things. - Can be nested. - Variations of packages are: Frameworks, models, & subsystems. Business rules

16. Unit I/UML/MCA/NIEVenkata Ratnam K16 4.Annotational Things  These are Explanatory parts of UML models  These are the Comments regarding other UML elements (usually called adornments in UML) There is one primary kind of annotational thing: 1.Note A note is simply a symbol for rendering constraints and comments attached to an element or collection of elements. Is a best expressed in informal or formal text. comments

17. Unit I/UML/MCA/NIEVenkata Ratnam K17 Relationships There are four kinds of relationships: 1. Dependency 2. Association 3. Generalization 4. Realization » These relationships tie things together. » It is a semantic connection among elements. » These relationships are the basic relational building blocks of the UML.

18. Unit I/UML/MCA/NIEVenkata Ratnam K18 1. Dependency Is a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing ( the dependent thing). 2.Association Is a structural relationship that describes a set of links, a link being a connection among objects. employeremployee 0..1 *

19. Unit I/UML/MCA/NIEVenkata Ratnam K19 Aggregation » Is a special kind of association. It represents a structural relationship between the whole and its parts. » Represented by black diamond. 3.Generalization Is a specialization/generalization relationship in which objects of the specialized element (the child) are more specific than the objects of the generalized element.

20. Unit I/UML/MCA/NIEVenkata Ratnam K20 4. Realization a semantic relationship between two elements, wherein one element guarantees to carry out what is expected by the otherelement. Where? Between interfaces and classes that realize them… Between use cases and the collaborations that realize them...

21. Unit I/UML/MCA/NIEVenkata Ratnam K21 Diagrams  A diagram is the graphical presentation of a set of elements.  Represented by a connected graph: Vertices are things; Arcs are behaviors. UML includes nine diagrams:  Use case Diagram  Class Diagram;  Object Diagram  Sequence Diagram;  Collaboration Diagram  Statechart Diagram  Activity Diagram  Component Diagram  Deployment Diagram

22. Unit I/UML/MCA/NIEVenkata Ratnam K22 1.Class Diagram  Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves.  A class diagram shows the existence of classes and their relationships in the logical view of a system These diagrams contain the following elements. – Classes and their structure and behavior – Association, aggregation, dependency, and inheritance relationships – Multiplicity and navigation indicators – Role names These diagrams are the most common diagrams found in O-O modeling systems.

23. Unit I/UML/MCA/NIEVenkata Ratnam K23 Examples: Registration Form Registration Manager Student Course Offering Course

24. Unit I/UML/MCA/NIEVenkata Ratnam K24 Example

25. Unit I/UML/MCA/NIEVenkata Ratnam K25 2. Object Diagrams  Shows a set of objects and their relationships.  A static snapshot of instances.  Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements: Objects which represent particular entities. These are instances of classes. Links which represent particular relationships between objects. These are instances of associations. Harry (Student) Name: “Harry Mat” Major: CS

26. Unit I/UML/MCA/NIEVenkata Ratnam K26

27. Unit I/UML/MCA/NIEVenkata Ratnam K27 Use case diagrams Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements: Actors : which represent users of a system, including human users and other systems. Use Cases : which represent functionality or services provided by a system to users. RegistrarStudent Maintain Schedule

28. Unit I/UML/MCA/NIEVenkata Ratnam K28 Example

29. Unit I/UML/MCA/NIEVenkata Ratnam K29 Sequence Diagrams Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements: Class roles: which represent roles that objects may play within the interaction. Lifelines which represent the existence of an object over a period of time. Activations : which represent the time during which an object is performing an operation. Messages : which represent communication between objects.

30. Unit I/UML/MCA/NIEVenkata Ratnam K30 Collaboration Diagram Collaboration Diagrams describe interactions among classes and associations. These interactions are modeled as exchanges of messages between classes through their associations. Collaboration diagrams are a type of interaction diagram. Collaboration diagrams contain the following elements. Class roles: which represent roles that objects may play within the interaction. Association roles: which represent roles that links may play within the interaction. Message flows: which represent messages sent between objects via links. Links transport or implement the delivery of the message.

31. Unit I/UML/MCA/NIEVenkata Ratnam K31

32. Unit I/UML/MCA/NIEVenkata Ratnam K32 Statechart Diagrams Statechart (or state) diagrams describe the states and responses of a class. Statechart diagrams describe the behavior of a class in response to external stimuli. These diagrams contain the following elements: States : which represent the situations during the life of an object in which it satisfies some condition, performs some activity, or waits for some occurrence. Transitions: which represent relationships between the different states of an object.

33. Unit I/UML/MCA/NIEVenkata Ratnam K33

34. Unit I/UML/MCA/NIEVenkata Ratnam K34 Activity Diagrams Activity diagrams describe the activities of a class. These diagrams are similar to statechart diagrams and use similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather than external events as in statechart diagram. Swimlanes: which represent responsibilities of one or more objects for actions within an overall activity; that is, they divide the activity states into groups and assign these groups to objects that must perform the activities. Action States: which represent atomic, or noninterruptible, actions of entities or steps in the execution of an algorithm. Action flows: which represent relationships between the different action states of an entity. Object flows: which represent the utilization of objects by action states and the influence of action states on objects.

35. Unit I/UML/MCA/NIEVenkata Ratnam K35

36. Unit I/UML/MCA/NIEVenkata Ratnam K36 Component Diagram Component diagrams describe the organizations and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units, including source code, object code, and executable code. These are static implementation view of a system. Deployment Diagrams Deployment diagrams describe the configuration of run-time processing resource elements and the mapping of software implementation components onto them. These diagrams contain components and nodes, which represent processing or computational resources, including computers, printers, etc.

37. Unit I/UML/MCA/NIEVenkata Ratnam K37 Rules of the UML:  The UML building blocks can’t simply put together in a random fashion.  Like any language, the UML has a number of rules that specify what a well-formed model should look like.  well-formed models Is a model semantically self-consistent and in harmony with all its related models Semantic rules for: Names — what you can call things. Scope — context that gives meaning to a name. Visibility — how names can be seen and used. Integrity — how things properly and consistently relate to one another. Execution — what it means to run or simulate a dynamic model.  Avoid models Elided — certain elements are hidden for simplicity. Incomplete — certain elements may be missing. Inconsistent — no guarantee of integrity.

38. Unit I/UML/MCA/NIEVenkata Ratnam K38 Common Mechanisms:  The UML is made simpler by the presence of some features called common mechanisms. There are four kinds of mechanisms; 1. Specifications: It provides a textual statement of the syntax and semantics of the building blocks. 2. Adornments: It provides detail from an element’s specification added to its basic graphical notation. 3. Common divisions: There is a division of class and object and also the division of interface and implementation. 4. Extensibility mechanisms: The UML provides a standard language for software blueprints. The UML is opened, making it possible to extend the language in controlled ways to express all possible nuances of all models across all time.

39. Unit I/UML/MCA/NIEVenkata Ratnam K39 The UML’s extensibility mechanisms include Stereotypes can be used to extend the UML notational elements (extends vocabulary.) » Name shown in guillements > » Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components » Examples: – Class stereotypes: boundary, control, entity, utility, exception – Inheritance stereotypes: includes and extends – Component stereotypes: subsystem Ex: >, >

40. Unit I/UML/MCA/NIEVenkata Ratnam K40 Tagged values — extends properties of UML building blocks. Placed in braces beneath the name of the element to which the property applies Ex: Constraints — extends the semantics of UML building blocks. A string placed in braces Ex: {and}, {or}, {abc} An Object: Class A {location=server)

41. Unit I/UML/MCA/NIEVenkata Ratnam K41 Architecture: Visualizing, specifying, constructing, and documenting a software system demands that the system be viewed from a number of perspectives. 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 of its lifecycle. s/w architecture is not only concerned with structure and behavior, but also it’s usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic concerns. The below figure illustrates, the architecture of a system can be described by five interlocking views.

42. Unit I/UML/MCA/NIEVenkata Ratnam K42 Modeling a system’s architecture Design ViewImplementation View Process View Components Classes, interfaces, collaborations Active classes Deployment View Nodes Use Case View Use cases Design ViewImplementation View Process View Components Classes, interfaces, collaborations Active classes Deployment View Nodes Use Case View Use cases

43. Unit I/UML/MCA/NIEVenkata Ratnam K43 Use case view Encompasses the use cases that describes the behavior of the system as seen by its end users, analysts, and testers Design view Encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution Process view Shows the flow of control among its various parts, including possible concurrency and synchronization mechanisms Implementation view Encompasses the artifacts that are used to assemble and release the physical system Deployment view Encompasses the nodes that form the system’s hardware topology on which the system executes

44. Unit I/UML/MCA/NIEVenkata Ratnam K44 Software Development Life Cycle The UML is largely process- independent To get the most benefit from the UML, you should consider a process that is Use case driven — use cases are primary artifact for defining 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 — the system’s architecture is primary artifact for conceptualizing, constructing, managing, and evolving the system under development. Iterative — managing streams of executable releases.

45. Unit I/UML/MCA/NIEVenkata Ratnam K45 Incremental One that involves the continuous integration of the system’s architecture to produce these releases This process is furthurly can be broken into phases. A Phase is the span of time between two major milestones of the process

46. Unit I/UML/MCA/NIEVenkata Ratnam K46 Lifecycle Phases  Inception Define the scope of the project and develop business case Deliver the product to its users  Elaboration Plan project, specify features, and baseline the architecture  Construction Build the product  Transition Turned over to the user community ` time InceptionElaborationConstructionTransition

47. Unit I/UML/MCA/NIEVenkata Ratnam K47 Advantages of UML  You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML.  Used for modeling middleware  Built upon the MOF™ meta model for OO modeling  UML Profiles (that is, subsets of UML tailored for specific purposes) help you model Transactional, Real-time, and Fault-Tolerant systems in a natural way.  UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation-independent manner 10-20% of the constructs are used 80-90% of the time Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior Use case modeling specifies the functional requirements of system in an object-oriented manner