UML

Unified Modeling Language : Unified Modeling Language

History of UML : History of UML In 1994, Grady Booch and James Rumbaugh, the two market share leaders in object-oriented (OO) software methods, formally joined forces to develop a notation standard. A year later, they published the Unified Method version 0.8. Ivar Jacobson, yet another leader in object-oriented development, joined the team. The team of Rumbaugh, Booch, and Jacobson were soon after dubbed the “three amigos” within OO circles . At the same time that the three amigos were working on their common notation, the Object Management Group (OMG) was establishing the Object-Oriented Analysis and Design (OOA&D) Task Force . By October 1996, a number of the leading application and modeling tool manufacturers, like IBM and i-Logix, had partnered with the three amigos to sponsor the UML proposal to the task force

The UML metamodel : The UML metamodel

UML and Development Methodologies : UML and Development Methodologies A methodology consists of a process, a vocabulary, and a set of rules and guidelines. The process defines a set of activities that together accomplish all the goals of the methodology . The Rational Unified Process works well in large projects where quality artifacts and communication are critical. The Shlaer-Mellor Method was developed primarily to address the unique needs of real-time systems long before the UML existed, but has since adopted the UML notation. CRC is almost more of a technique than a methodology. It was designed as a tool to help people gain an understanding of objects and how they work. Extreme Programming tries to reduce many of the existing development practices to the bare essentials, attempting to optimize the relationship between developers and clients.

The Rational Unified Process : The Rational Unified Process RUP is the latest version of a series of methodologies resulting from a blending of methodologies. It consists of- Objectory Process, the Rational Approach, the Rational Objectory Process, and the Unified Software Development Process. These were all predecessors and have been synthesized into the RUP It is represented as a two-dimensional matrix. The horizontal axis represents the progress of the project over time. The vertical axis represents the core process workflow. Using this visualization, we can see that in each iteration, or small step through the life of the project, the team is working through all the steps in the process workflow

Shlaer-Mellor Method : Shlaer-Mellor Method The Shlaer-Mellor Method is based on an integrated set of models that can be executed for verification, and an innovative approach to design that produces a system design through a translation of the analysis models . 1. Partition the system into domains. 2. Analyze the application domain using object information models, state models, and action specifications (action data flow diagrams). 3. Confirm the analysis through static and dynamic verification 4. Extract the requirements for the service domains. 5. Analyze the service domains. 6. Specify the components of the architectural domain. 7. Build the architectural components. 8. Translate the models of each domain using the architectural components

CRC : CRC CRC stands for Class, Responsibilities, and Collaborators. The CRC methodology was originally developed as a learning tool during the time when object-oriented programming was new; a lot of procedural programmers needed help making the transition to OO thinking . A CRC card is a 3-x-5" or 4-x-6" lined index card. The physical nature of the cards emphasizes the division of responsibility across objects. The physical size of the cards also helps to establish limits for the size and complexity of the classes

Extreme Programming : Extreme Programming XP basically says that the code is everything, so there is a very heavy emphasis on coding standards and design principles. The process includes numerous standup meetings to keep everyone on the same page. Furthermore, programmers work in pairs so that they can learn from one another, provide insights, share design alternatives, and generally help each other out

Diagram based approach of UML : Diagram based approach of UML One way to organize the UML diagrams is by using views. A view is a collection of diagrams that describe a similar aspect of the project. We very often use a set of three distinct yet complementary views that are called the Static View, Dynamic View, and Functional View.

Functional View : Functional View In the Functional View, we include both the Use Case diagram and the Activity diagram. We keep them together because they are used together so often and they both model how the system is supposed to work

Static View : Static View The Static View includes those diagrams that provide a snapshot of the elements of the system but don’t tell you how the elements will behave. It is very much like a blueprint. Blueprints are comprehensive, but they only show what remains stationary, hence the term Static View.

Dynamic View : Dynamic View It includes the Sequence and Collaboration diagrams, which collectively are referred to as interaction diagrams. They are specifically designed to describe how objects talk to each other. It also includes the State chart diagram, which shows how and why an object changes over time in response to the environment.

Types of Requirements : Types of Requirements In a software project, we most often supporting business processes. But we may also be supporting automation of mechanical processes in a factory setting, or real-time processing inside equipment like a heart monitor . Different types of requirements include- 1. Business Process 2. Constraints 3. Rules 4. Performance

Slide 14 : Business process . Business processes describe your relationship with the system in terms of interactions. . A common challenge with gathering business processes is that it is difficult to distinguish personal preference or legacy practice from actual current need. Constraint Constraints are limitations on or boundaries around what you can do when you develop a solution for the system. Constraints can apply to virtually any aspect of your project and the resulting system . Rules Rules are more like agreements. Rules can be anything from the look of a form or screen, to a business process with checks and approvals, number of copies, and waiting periods Performance Performance requirements define how well the system solution should perform when you use it. The challenge here is that the means to achieve the required performance may require choices at any or all the project phases

Use Case Model : Use Case Model The Use Case model is a collection of diagrams and text that together document how users expect to interact with the system. The Use Case model focuses on the critical success factors of the system, in terms of the functionality or features that the users need to interact with. The key difference between Use Cases and functional design is the focus. Functional design documents a process, but a Use Case focuses on the goal of a process.

Slide 16 : Use Case diagram The Use Case diagram consists of five very simple graphics that represent the system, actors, Use Cases, associations, and dependencies of the project. The goal of the diagram is to provide a high-level explanation of the relationship between the system and the outside world. Use Case narrative The Use Case narrative provides a fairly standard (yet user-defined) set of information that is required to guide the analysis, design, and coding of the feature. Use Case scenarios Use Case scenario is one logical path through a Use Case, one possible sequence of steps in the execution of the Use Case. A Use Case may include any number of scenarios.

Slide 17 : Elements of Use Case Diagram 1. System: Sets the boundary of the system in relation to the actors who use it and the features it must provide. 2. Actor: A role played by a person, system, or device that has a stake in the successful operation of the system. 3. Use Case: Identifies a key feature of the system. Without these features, the system will not fulfill the user/actor requirements. Each Use Case expresses a goal that the system must achieve. 4. Association: Identifies an interaction between actors and Use Cases. Each association becomes a dialog that must be explained in a Use Case narrative. Each narrative in turn provides a set of scenarios that function as test cases when evaluating the analysis, design, and implementation of the Use Case. 5. Dependency: Identifies a communication relationship between two Use Cases. 6. Generalization: Defines a relationship between two actors or two Use Cases where one Use Case inherits and adds to or overrides the properties of the other.

Building Use Case Diagram : Building Use Case Diagram Step 1: Set the context of the target system. Step 2: Identify the actors Find the people, systems, or devices that communicate with the system. Step 3: Identify the Use Cases Step 4: Define the associations between actors and Use Cases Identify the actor who need access to each Use Case/feature of the system. Step 5: Evaluate the actors and Use Cases to find opportunities for refinement Rename, Step 6: Evaluate the Use Cases for <> dependencies Step 7: Evaluate the Use Cases for <> dependencies. Step 8: Evaluate the actors and Use Cases for generalization

Building the use case model : Building the use case model 1. Assumptions 2. Pre-conditions 3. Use Case initiation 4. Process or dialog 5. Use Case termination 6. Post-conditions

Identifying Use Case Scenarios : Identifying Use Case Scenarios Each possible outcome of an attempt to accomplish a Use Case goal is called a scenario. A scenario is a single logical path through a Use Case. We can call a scenario an instance of a Use Case in that a scenario is one realization, or execution, of the conceptual Use Case. In other words, a Use Case defines what could happen, whereas a scenario defines what does happen under a given set of conditions

Building Class Diagrams : Building Class Diagrams The Class diagram is by far the most used and best known of the object-oriented diagrams. It is the source for generating code and the target for reverse engineering code.

Slide 22 : The Sequence and Collaboration diagrams are excellent tools for discovering object interactions and, by inference, defining interfaces. The Activity diagram is very good for discovering the behavior implemented by objects and so helps to define the logic of operations on the objects. Object Model is often used as a synonym for Class diagram. The object model is used to mean the set of diagrams used to model objects, namely the Class and Object diagrams.

Slide 23 : 1. Attributes describe the appearance and knowledge of a class of objects. 2. Operations define the behavior that a class of objects can manifest. 3. Stereotypes help you understand this type of object in the context of other classes of objects with similar roles within the system’s design. 4. Properties provide a way to track the maintenance and status of the class definition. 5. Association is just a formal term for a type of relationship that this type of object may participate in. Associations may come in many variations, including simple, aggregate and composite, qualified, and reflexive. 6. Inheritance allows you to organize the class definitions to simplify and facilitate their implementation.

Associations between class diagrams : Associations between class diagrams Associations between objects are similar to associations between people. In order to run a process it is important for the classes to communicate with each other. Therefore it is important to create associations.

Slide 25 : To draw the UML associations for these three examples, you need to start with four basic elements. 1. The participating classes. 2. The association, represented by a line between the two classes. 3. The name of the association, represented by a verb or verb phrase on the association line. 4. The direction to read the name (indicating the direction is optional).

Class Aggregation and Generalization : Class Aggregation and Generalization Aggregation is a special type of association used to indicate that the participating objects are not just independent objects that know about each other. Instead, they are assembled or configured together to create a new, more complex object. Composition is used for aggregations where the life span of the part depends on the life span of the aggregate. Generalization is the process of organizing the properties of a set of objects that share the same purpose. People use this process routinely to organize large amounts of information.

Aggregation Composition and Generalization : Aggregation Composition and Generalization

Modeling the static view : Modeling the static view The static view of UML consists of object diagrams etc. The Object diagram consists of just two elements: objects and links. An object is a real entity created from a class, a definition of a type of object. A link represents a relationship between two objects..

Activity Diagram : Activity Diagram The Activity diagram is part of the Functional view because it describes logical processes, or functions, implemented using code. Each process describes a sequence of tasks and the decisions that govern when and how they are done.

Slide 30 : An activity is a step in a process where some work is getting done. It can be a calculation, finding some data, manipulating information, or verifying data. The activity is represented by a rounded rectangle containing freeform text. An Activity diagram is a series of activities linked by transitions, arrows connecting each activity. Sometimes the transition should only be used when certain things have happened.

The sequence diagram : The sequence diagram The Sequence diagram illustrates the interactions between objects. Interactions show us how objects talk to each other. Each time that one object talks to another it talks to an interface (that is, it invokes an operation).

Slide 32 : All Sequence diagrams are modeled at the object level rather than the class level to allow for scenarios that use more than one instance of the same class and to work at the level of facts, test data, and examples. The Sequence diagram uses three fundamental notation elements: objects, messages/stimuli, and object lifeline.

The collaboration diagram : The collaboration diagram Collaboration diagram models the messages on top of an Object diagram. The Collaboration diagram uses this approach in order to emphasize the effect of the object structures on the interactions.

Slide 34 : The Collaboration diagram provides a tool for visually assigning responsibilities to objects for sending and receiving messages. By identifying an object as the receiver of a message, you are in effect assigning an interface to that object. It is kind of like receiving phone calls.

The statechart diagram : The statechart diagram The State chart describes the life of an object in terms of the events that trigger changes in the object’s state. It identifies both the external events and internal events that can change the object’s state. The state of the object is simply its current condition.

Slide 36 : The State chart models the events that trigger a transition (change) from one state to another state. Each event may have a corresponding action that makes the changes in the object (that is, alters the attribute values). The State chart can also be used to model concurrent activities within a state by creating parallel substates within a super state. Using the substrate and super state notation, we can explicitly identify split and merge of control for concurrency. The internal transitions compartment contains information about actions and activities specific to that state.