uml

UML:

UML Suryakumar Ramalingam Solutions Architect ramsuri@gmail.com

What is Modeling:

ramsuri@gmail.com What is Modeling A software development method consists of a modeling language and a process. The Unified Modeling Language (UML) is called a modeling language, not a method. The modeling language is the notation that methods use to express designs. The process describes the steps taken in doing a design.

Models:

ramsuri@gmail.com Models Models provide various perspectives, when put together will provide an overall view of the system. Creating a model for a given level of abstraction decides which elements are to be included and which are to be excluded. The notation often takes the form of graphical symbols and connections. Models in software help us to visualize, specify, construct and document the artifacts of a software intensive system.

Business Modeling:

ramsuri@gmail.com Business Modeling UML is used for modeling business process. Business models provide ways of expressing the business processes in terms of business activities and collaborative behavior. Business modeling is a technique which will help in finding out whether we have identified all the system use cases as well as determining the business value of the system.

Why Business Modeling:

ramsuri@gmail.com Why Business Modeling The system can provide value only if we know how it will be used, who will use it and in what circumstances it will be used. To ensure that customer-oriented solutions are built, we must not overlook the environment in which these systems will work the roles and responsibilities of the employees using the system the "things" that are handled by the business, as a basis for building the system great benefits of business modeling elicit better system requirements, requirements that will drive the creation of information systems that actually fit in the organization and that will indeed be used by end-users.

Unified Process:

ramsuri@gmail.com Unified Process Process is a set of activities intended to reach a goal. The inputs to the software process are the needs of the business and the output will be the software product. The Unified Process is one such lifecycle approach well-suited to the UML. the Unified Process provides a disciplined approach on how to assign tasks and responsibilities within a software development organization. The Unified Process is iterative, incremental, architecture-centric, use-case driven.

Unified Modeling:

ramsuri@gmail.com Unified Modeling

Inception phase:

ramsuri@gmail.com Inception phase During the inception phase, we develop business model for the project. The feasibility study is performed as well as the overall scope and size of the project is determined during the inception phase. The actors of the system and their interaction with the system are analyzed at a high level. At the end of the Inception stage, the following objectives are to be achieved: Concurrence on the scope of the project and the estimates Understanding of the requirements

Elaboration phase:

ramsuri@gmail.com Elaboration phase In the elaboration phase, a baseline architecture is established, the project plan is developed and risk assessment is also performed. The major types of risks are Requirements Risks Technological Risks Skills Risks Political Risks

Elaboration Phase:

ramsuri@gmail.com Elaboration Phase At the end of the elaboration The use case model should be complete Nonfunctional Requirements should be elaborated Software Architecture should be described Revised risk list should be present A preliminary user manual (optional)

Construction phase:

ramsuri@gmail.com Construction phase All the components are developed and the components are integrated during the construction phase. All the features are completely tested during this stage. Resources are managed and operations are controlled to optimize cost, schedule and quality. The construction phase is incremental and iterative. Refactoring is done after every iteration. At the end of the construction, The product should be stable and mature for release Actual versus planned expenditure should be acceptable

Transition phase:

ramsuri@gmail.com Transition phase The objective of this phase is to transition the software product to the user community. new releases, correcting defects and optimization are part of this phase. The activities in this phase include User Training Conversion of Operational databases Roll out the product to marketing and sales

Transition Phase:

ramsuri@gmail.com Transition Phase The objectives of the transition phase are Customer Satisfaction Achieving the concurrence of the stakeholders that the deployment baselines are complete and consistent with the evaluation criteria Achieving final product baseline rapidly in a cost effective manner

Parts of UML:

ramsuri@gmail.com Parts of UML The UML is composed of three different parts: Model elements - The model elements represent basic object-oriented concepts such as classes, objects, and relationships. Diagrams - portray different combinations of model elements. The UML provides nine types of diagram - use case, class, object, state chart, sequence, collaboration, activity, component, and deployment Views - provide the highest level of abstraction for analyzing the system.

5 Main Views in UML:

ramsuri@gmail.com 5 Main Views in UML

Use Case Diagrams:

ramsuri@gmail.com Use Case Diagrams The use case diagram presents an outside view of the system Creating a use-case model involves the following steps: defining the system identifying the actors and the use cases describing the use cases defining the relationships between use cases and actors. defining the relationships between the use cases

Notations:

ramsuri@gmail.com Notations Notation of use case Notation for Actor Relation: Include– An Include relationship shows behavior that is common to one or more use cases (Mandatory) Extend – An extend relationship shows optional behavior (Optional) System boundary rectangle separates the clinic system from the external actors. <<extends>>

Class Diagrams:

ramsuri@gmail.com Class Diagrams shows the existence of classes and their relationships in the structural view of a system. Classes and their structure and behavior Relationships Association Aggregation Composition Dependency Generalization / Specialization ( inheritance relationships) Multiplicity and navigation indicators Role names

Class Diagram - Notation:

ramsuri@gmail.com Class Diagram - Notation

Relationship - Association:

ramsuri@gmail.com Relationship - Association

Relationship - Aggregation:

ramsuri@gmail.com Relationship - Aggregation

Relationship - Composition:

ramsuri@gmail.com Relationship - Composition

Relationship - Dependency:

ramsuri@gmail.com Relationship - Dependency

Relationship - Generalization:

ramsuri@gmail.com Relationship - Generalization

Association Classes:

ramsuri@gmail.com Association Classes An association class is an association that also has class properties(or a class has association properties)

Constraint:

ramsuri@gmail.com Constraint

interface is a specifier:

ramsuri@gmail.com interface is a specifier

Qualifier is an attribute :

ramsuri@gmail.com Qualifier is an attribute

Interaction Diagrams:

ramsuri@gmail.com Interaction Diagrams is used to model the dynamic behavior of the system helps us to identify the classes and its methods Interaction diagrams describe how use cases are realized as interactions among objects There are two types of interaction diagrams Sequence Diagram Collaboration Diagram

Sequence diagram:

ramsuri@gmail.com Sequence diagram show the interaction of objects with respect to time Sequence diagrams have two axes horizontal axis represents the objects involved in a sequence. vertical axis represents the passage of time

Sequence Diagram:

ramsuri@gmail.com Sequence Diagram

Collaboration diagram:

ramsuri@gmail.com Collaboration diagram shows the interaction of the objects and also the group of all messages sent or received by an object. allows us to see the complete set of services that an object must provide.

Collaboration Diagram:

ramsuri@gmail.com Collaboration Diagram

Activity Diagram:

ramsuri@gmail.com Activity Diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. on the flow of activities involved in a single process. shows the how those activities depend on one another

Activity Diagram:

ramsuri@gmail.com Activity Diagram

State Chart Diagram:

ramsuri@gmail.com State Chart Diagram A state chart (transition) diagram is used to show The life history of a given class, usecase, operation 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 (More Contents are to be added)

Activity Diagram:

ramsuri@gmail.com Activity Diagram

Component Diagram:

ramsuri@gmail.com Component Diagram Describe organization and dependency between the software implementation components. Components are distributable physical units - e.g. source code, object code.

Deployment Diagram:

ramsuri@gmail.com Deployment Diagram Describe the configuration of processing resource elements and the mapping of software implementation components onto them. Contain components - e.g. object code, source code and nodes (e.g. printer, database, client machine)

Deployment Diagram:

ramsuri@gmail.com Deployment Diagram