OBJECT ORIENTED ANALYSIS AND DESIGN (UNIFIED MODELING LANGUAGE)

OBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUSUNIT - IIntroduction to UML: Importance of modeling, principles of modeling, object oriented modeling, conceptual model of the UML, Architecture, Software Development Life Cycle.UNIT - IIBasic Structural Modeling: Classes, Relationships, common Mechanisms, and diagrams. Advanced Structural Modeling: Advanced classes, advanced relationships, Interfaces, Types and Roles, Packages.UNIT - IIIClass & Object Diagrams: Terms, concepts, modeling techniques for Class & Object Diagrams.UNIT - IVBasic Behavioral Modeling-I: Interactions, Interaction diagrams.*

UNIT-VBasic Behavioral Modeling-II: Use cases, Use case Diagrams, Activity Diagrams.UNIT - VIAdvanced Behavioral Modeling: Events and signals, state machines, processes and Threads, time and space, state chart diagrams.UNIT - VIIArchitectural Modeling: Component, Deployment, Component diagrams and Deployment diagrams.UNIT - VIIICase Study: The Unified Library application

1. Grady Booch, James Rumbaugh, Ivar Jacobson : The Unified Modeling Language User Guide, Pearson Education.2. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado: UML 2 Toolkit, WILEY-Dreamtech India Pvt. Ltd.

REFERENCES:1. Meilir Page-Jones: Fundamentals of Object Oriented Design in UML, Pearson Education.2. Pascal Roques: Modeling Software Systems Using UML2, WILEY-Dreamtech India Pvt. Ltd.3. Atul Kahate: Object Oriented Analysis & Design, The McGraw-Hill Companies.4. Mark Priestley: Practical Object-Oriented Design with UML,TATA McGrawHill5. Craig Larman Appling UML and Patterns: An introduction to Object Oriented Analysis and Design and Unified Process, Pearson Education.TEXT BOOKS

UMLUML stands for Unified Modeling Language.Why Unified ?James Rumbaugh, Grady Booch, and Ivar Jacobson developed 3 different notations. But later agreed to adopt as standard a variation on a notation originally developed by David Embley and his colleagues.

UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs.

UML is a common language for creating models of Object Oriented Programming.*

But what is the need to study UML?An AnalogyGround Floor Plan Floor Area : 66 sq mMin Lot Area : 120 sq mLiving Area, Kitchen and Dining AreaDining is right to the kitchen.Entrance is on right with living space, following the kitchen and dining.2 bedrooms2 T&B

Written specifications or the model?Que: What is more appealing?

*

The reason we want to see a picture is that human beings naturally want to communicate in the simplest form possible. We say, a picture is worth a thousand words.

*

Unit I : Introduction to UML ContentsChapter -1 : Why we model?Importance of modeling, Principles of modeling, Object oriented modeling,

Chapter 2 : Introducing the UMLConceptual model of the UML, Architecture, Software development life cycle. *

CHAPTER-1 Why We Model Firstly, understand what is Successful softwareThe Primary product of a development team is good software that satisfies the needs of its users and the business. To develop software rapidly, efficiently, effectively and minimum software rework, we need right people, right tools, and right focus.*

Modeling is a central part of all the activities that lead to the development of good software.

Modeling is a proven and well accepted engineering tech.

*

We build models toTo Communicate the desired structure and behavior of our system.

To visualize and control the systems architecture.

To better understanding the system we are building often exposing opportunities for simplification and reuse.

To manage risk.*

1. Importance of ModelingWhat is a model?A Model is a simplification of reality.It provides the blue prints of a system.

A good model includes the elements which have greater importance and omits minor elements which are of lower importance

*

Why model software?Software is already an abstraction: why model software?

Software is getting larger, not smallerNT 5.0 ~ 40 million lines of codeA single programmer cannot manage this amount of code in its entirety.

Code is often not directly understandable by developers who did not participate in the development

We need simpler representations for complex systemsModeling is a mean for dealing with complexity

Why do we model?The fundamental reason to have a model is we can better understand the system we are developing.

Through modeling, we can achieve the following 4 aims:-1) Models help us to visualize a system as it is or as we want it to be.

2) Models permits us to specify the structure orbehavior of a system.

3)Models give us a template that guides us in constructing a system.

4) Models document the decision we have made.*

2. Principles of ModelingThe use of modeling has a rich history in all the engineering disciplines. The four basic principles of modeling are:

The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.

In other words, choose your models well. The right models will brilliantly illuminate the most wicked development problems, the wrong models will mislead you, causing you to focus on irrelevant issues.*

In software, the models you choose can greatly affect your world view. If you build a system through the eyes of a database developer, you will likely focus on ? And so on2.Every model may be expressed at different levels of precision.For a building sometimes you need a 30,000 feet view for investors look and feel other times, you need to get down to some other level like pipelines etc.Similarly analyst or an end user will focus on issues of what, a developer will want to focus on issues of how.

The best models are connected to reality.

No single model is sufficient. Every non trivial system is best approached through a small set of nearly independent models.*

To understand the architecture of a system, you need several complementary and interlocking views:-A Use Case viewA Design process viewA Process viewAn implementation viewA Deployment view

*

A Use Case view: Exposing the requirements of the system.A Design process view: Capturing the vocabulary of the problem space and the solution space.A Process view: Modeling the distribution of the systems processes and threads.An Implementation view: Addressing the physical realization of the system.A Deployment view: Focusing on systems engineering issues. These views represent the blueprints of the software system.

*

3. Object-Oriented ModelingIn software, the two most common approaches used are algorithmic perspective and an object-oriented perspective.

In algorithmic perspective, the main building block of all software is the procedure or function. This view leads developers to focus on issues of control and the decomposition of larger algorithms into smaller ones.

2.In object-oriented perspective, the main building block is the object or the class.*

In object-oriented perspective, the main building block is the object or the class.In this approach, the main building block of all software systems is the object or class. Simply put An object is a thing, and a class is a description of a set of common objects.

3. Visualizing, specifying, constructing and documenting object-oriented system is exactly the purpose of UML

Summary of chapter 1Importance of modelingvisualize a system.specify the structure or behavior of a system.template that guides us in constructing a system.document the decision

Principles of modeling, what models to createEvery model may be expressed at different levels of precision.The best models are connected to reality.No single model is sufficient.

Object oriented modelingalgorithmic perspective, object-oriented perspective*

INTRODUCTION TO UMLCHAPTER 2

Chapter 2 : Introducing the UML

In this chapterOverview of the UMLThree steps to understanding the UMLSoftware ArchitectureThe Software Development Process

Introduction To UML The Unified Modeling Language (UML) is a standard language for writing software blue prints.

It is appropriate for modeling systems ranging from enterprise information systems to distributed web-based applications and even real time embedded systems.

Very expressive, easy to learn and use.

The UML is process independent.

Overview of UMLThe UML is a language for

Visualizing Specifying Constructing Documenting

the artifacts of software-intensive system. *

The UML is a Language.What is a Language?What is a modeling language?

Its a language whose vocabulary and rules focus on the conceptual and physical representation of a system.

Modeling yields an understanding of a system*

a. UML is a language for visualizingFor many programmers, the distance between thinking of an implementation, and then delivering it out in code is close to zero. Means you think and you code or do directly

Text is a wonderful, minimal and direct way to write expressions and algorithms.

In such cases, the programmer is still doing modeling (Of course mentally). Overview of UMLVisualizing Specifying Constructing Documenting

There are several problems with thisCommunicating the conceptual models to others is error-prone unless everyone involved speaks the same language.

SoUML is more than a bunch of graphical symbols and each UML notations have a well defined semantics.Overview of UMLVisualizing Specifying Constructing Documenting

2)There are some things about a software system you cant understand unless you build models that transcend the textual programming language. (Example : Class hierarchy) Some things are best modeled textually, others are best modeled graphically. Indeed, in all interesting systems, there are structures that transcend what can be represented in a programming language. The UML is such a graphical language.Overview of UMLVisualizing Specifying Constructing Documenting

3) If the developer who cut the code never wrote down the models that were in his/her head, that information would be lost forever or, at best, only partially recreatable from the implementation, once that developer moved on.

Writing models in the UML addresses the third issue: An explicit model facilities communication.Overview of UMLVisualizing Specifying Constructing Documenting

b. UML is a language for SpecifyingSpecifying means building models that are precise, unambiguous and complete.

The UML addresses the specification of all the important analysis, design and implementation decisions that must be made in developing and deploying a software system.Overview of UMLVisualizing Specifying Constructing Documenting

c. UML is a language for ConstructingThe UML is not a visual programming language, but its models can be directly connected to a variety of programming languages, such as JAVA, C++ or Visual Basic or even to Tables of database.

Forward Engineering: generation of code in programming language from UML model.Reverse Engineering : reconstructing an UML model from an implementation *Overview of UMLVisualizing Specifying Constructing Documenting

d. UML is a language for DocumentingA software organization produces all sorts of artifacts in addition to row executable code. The artifacts including the following:

-Requirements -Project Plan-Architecture -Tests-Design -Prototypes -Source Code -Releases.

Overview of UMLVisualizing Specifying Constructing Documenting

Where can be UML usedThe UML is intended primarily for Software intensive systems. It has been used effectively for such domains as follows:Enterprise information systemsBanking and financial servicesTelecommunicationsTransportationDefense Medical Electronics, Scientific and Distributed web-based services.

4. A Conceptual Model of the UMLTo understand the UML, a conceptual model of the language is needed to form,it requires the three major elements:

Building blocks of the UML.Rules that dictate how these building blocks may be put together.Common mechanisms that apply throughout the UML. *

1. Building blocks of the UMLThe UML consists of three kinds of building blocks:

Things- These are the abstractions that are first-class citizens in a model.

Relationships-Tie the above things together.

Diagrams-Group interesting collections of things,*

Things in the UMLThere are 4 kinds of things in the UMLStructural ThingsBehavioral ThingsGrouping ThingsAnnotational Things*UML TerminologyThingsRelationshipsDiagramsStructural (7) Behavioral (2)Grouping (1)Annotational (1)Building blocks

1. Structural ThingsNouns of UML models. Mostly static parts of a model, representing elements that are either conceptual or physical.7 kinds of Structural things:

ClassInterfaceCollaborationUse caseActive classComponentNode*

Class:- A 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. NameAttributesOperationclass

(2) InterfaceInterface is a collection of operations that specify a service of a class or component.

An interface describes the externally visible behavior of that element.

*

An interface defines a set of operation specifications but never a set of operation implementations.

Graphically, an interface is represented as a circle with its name.

ISpellingInterface

(3) Collaboration:-defines an interaction and is a society of roles and other elements. they work together to provide some cooperative behavior.

Therefore, collaboration have structural as well as behavioral dimensions.

Graphically a collaboration is represented as an ellipse with dashed lines, usually including only its name.

Chain of responsibility

(4) Use case:-A Use case is a description of set of sequence of actions that a system performs, which results a value to a particular actor.

A use case is used to structure the behavioral things in a model.

A use case is realized by a collaboration.

Withdraw moneyUse case*

The remaining three things- Active classes, components and nodes- all are class like, ie., they also describe a set of objects that share the same attributes, operations, relationships and semantics.

(5) Active class:- An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity.

An Active class is like a class except that its objects represent elements whose behavior is concurrent with other elements.*

Graphically, an active class is represented like a class, but with heavy lines, usually including its name, attributes and operations.Active class*

The remaining two elements component and nodes- they represent physical things, where as previous five things ( class, interface, collaboration, usecase, active class) represent conceptual or logical things.*

(6) Component:-A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.

A component represents the physical packaging of logical elements such as classes, interfaces and collaborations.*

Component

(7) Node:- A node is physical element that exists at run-time and represents a computational resource, generally having some memory and processing capability.

A set of components may reside on a node and may also migrate from node to node.

Node

2. Behavioral ThingsThese are the dynamic parts of UML models.These are the verbs of a model representing the behavior over time and space.There are two types of behavioral things 1. Interaction 2. State machine.

(1) Interaction:-An Interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to perform a specific purpose.

Messagedisplay*

An interaction involves a number of other elements, including messages, action sequences and links. (connection between objects.)

2. State machine:- A 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.

waitingState*

A State machine involves a number of other elements, including states, transitions( the flow from state to state), events (things that trigger a transition), and activities ( the response to a transition).

3. Grouping ThingsGrouping things are the organizational parts of UML models.In all, there is one primary kind of grouping thing, namely, Package.Package:- A Package is a general-purpose mechanism for organizing elements into groups.

Structural things, behavioral things and even other grouping things that may be placed in a package.

Unlike component (which exist at run time), package is purely conceptual (meaning that it exist only at development time).Business rulesPackage

4. Annotational ThingsAnnotational Things are the explanatory parts of the UML models.

These are the comments you may apply to describe, illuminate and remark about any element in a model.

There is one primary kind of Annotational thing, called a Note.

*

Note:- A Note is simply a symbol for representing constraints and comments attached to an element or a collection of elements.A note is rendered as a rectangle with a dog-eared corner.

Return copy of selfNote*

2. Relationships in the UMLThere are four kinds of relationships in the UML. 1. Dependency 2. Association 3. Generalization 4. Realization These relationships are the basic relational building blocks of the UML. These are used to write well-formed models. *

DEPENDENCY:-

A 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). *

In UML, a dependency relationship is a relationship in which one element, the client, uses or depends on another element, the supplier. You can use dependency relationships in class diagrams, component diagrams, deployment diagrams, and use-case diagrams to indicate that a change to the supplier might require a change to the client.

ASSOCIATION:-

In UML diagrams, an association class is a class that is part of an association relationship between two other classes. An Association is a structural relationship that describes a set of links, a link being a connecting among objects.When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:

An association is represented as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names.

GENERALIZATION:-

A generalization is a specialization/generalization relationship in which objects of the specialized elements (the child) are substitutable for objects of the generalized elements (the parent).In this way, the child shares the structure and the behavior of the parent.Represented as a solid line with a hollow arrow head pointing to the parent.

Generalization

A Generalization is relationship between a general thing( called the Super class or parent) and a more specific kind of that thing( called the Subclass or child).

Generalization is sometimes called is-a-kind of relationship.

Generalization means that objects of the child may be used anywhere the parent may appear, but not the reverse.

AGGREGATION:-

A plain association between two classes represents a structural relationship between peers.

To model a Whole/part relationship, in which one class represents a large thing( the whole), which consists of smaller things ( the Parts).

This kind of relationship is called AGGREGATION, which represents a has-a relationship, meaning that an object of the whole has objects of the part.

Aggregation is really just a special kind of association and is specified by adorning a plain association with an open diamond at the whole end.Composition:-Composition is a special form of aggregation within which the parts are inseparable from the whole.

REALIZATION:-

A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carryout.

We will encounter realization relationships in two places: between interfaces and classes or components that realize them, and between use cases and the collaborations that realize them. Realization

3. Diagrams in the UMLA diagram is the graphically presentation of a set of elements, most often represented as a connected graph of vertices (things) and arcs (relationships).

Diagrams visualize a system from different perspectives, so a diagram is a projection into system.

Diagrams in UML

The UML includes nine diagrams:Class diagramObject diagramComponent diagramDeployment diagramActivity diagramSequence diagramCollaboration diagramState chart diagramUse case diagramThis describe the static part of a system representedThis describe the dynamic part of a system represented

1. Class DiagramIt shows a set of classes, interfaces, and collaborations and their relationships.most common diagrams found in modeling object-oriented systems.address the static design view of a system.

2. Object DiagramAn object diagram shows a set of objects and their relationships.Object diagrams represent static snapshots of instances of the things found in class diagram

3. Component DiagramA component diagram shows the organizations and dependencies among a set of components.Component diagram address the static implementation view of a system.

4. Deployment DiagramA deployment diagram shows the configuration of run-time processing nodes and the components that live on them.Deployment diagram address the static deployment view of an architecture. *

5. 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 diagram address the dynamic view of a system.

(6) & (7) Sequence and Collaboration diagramsBoth sequence diagrams and collaboration are kind of interaction diagrams.

An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them.

Interaction diagram 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 take one and transform it into the other.

8. State Chart Diagram

A statechart diagram shows a state machine, consisting of states, transitions, events and activities.Statechart diagram address the dynamic view of a system.

9. UseCase DiagramUse case diagram shows a set of use case and actors (a special kind of class) 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

2. Rules of the UML:-The UMLs building blocks cant simply be thrown 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.

A Well-formed model is one that is semantically self-consistent and in harmony with all its related models.

The UML has semantic rules for:-

Names- What you can call things, relationships and diagrams.Scope- The context that gives specific meaning to a name.Visibility- How those names can be seen and used by others.Integrity- How things properly and consistently relate to one another.Execution- What it means to run or simulate a dynamic model.

3.Common MechanismsThe 4 common mechanisms that apply consistently throughout the language.

SpecificationsAdornmentsCommon DivisionsExtensibility mechanisms*

Specifications:-

The UML is more than just a graphical language. Rather, behind every part of graphical notation there is a specification that provides a textual statement of the syntax and semantics of that building block.

For example, behind a class icon is a specification that provides the full set of attributes, operations and behaviors.

You use the UMLs graphical notation to visualize a system; you use the UMLs specification to state the system details.

2. Adornments:-Adornments Textual/Graphical items added to the basic notation of an element.Used for visualizing details from the elements specificationExample: The basic notation of association is a line, but this could be adorned with additional details, such as the role and multiplicity of each end.The most important kind of adornments are notes.

EmployerEmployee0..1**

3.Common Divisions Abstraction vs. manifestationClass vs. objectMost UML building blocks have this kind of class/object distinction.

Interface vs. implementationAn interface declares a contract, and an implementation represents one concrete realization of that contract.

4.Extensibility MechanismsAllows you to extend the language by adding new building blocks derived from existing ones, creating new properties and specifying new semantics. Includes:

StereotypesTagged valuesConstraints*

StereotypesExtend the vocabulary of the UML by creating new model elements derived from existing ones but that have specific properties suitable for your domain/problem.

Each stereotype defines a set of properties that are received by elements of that stereotype.

Graphically, a stereotype is rendered as a name enclosed by guillemots and placed above the name of another element (eg, )

Alternatively, you can render the stereotyped element by using a new icon associated with that stereotype

Example: How many types of classes are there. Like you have Abstract Class, Derived Class, Exception Class, Constraint Class etc..

In Java, you sometimes have to model Classes such as exceptions.Only want them to be thrown and caughtCan make them first class citizens in your model, ie treating them like basic building blocks, by marking them with a suitable stereotype.

Named stereotype

Named stereotype with icon

Stereotyped element as icon

2.Tagged Values:-

Properties for specifying key-value pairs of model elements, where keywords are attributes.

Extend the properties of a UML building block, allowing you to create new information in that elements specification.

Can be defined for existing elements of the UML

3.Constraints:-

Properties for specifying semantics or conditions that must be maintained as true for model elements.

Extend the semantics of a UML building block, allowing you to add new rules, or modify existing ones.

Example:- you might want to constrain the EventQueue class so that all additions are done in order.

ArchitectureVisualizing, specifying, constructing, and documenting a software-intensive system demands that the system be viewed from a number of perspectives.

Different stakeholders areend users, analysts, developers, system integrators, testers, technical writers, and project managerseach bring different agendas to a project,each looks at that system in different ways at different times

System's architectureMost important artifact Used to manage different viewpoints; hence controls iterative and incremental development of a system throughout its life cycle.Architecture is the set of significant decisions aboutOrganization of a software systemSelection of the structural elements and their interfaces by which the system is composedTheir Behavior, specified in the collaborations among elements.Composition of these structural and behavioral elements into progressively larger subsystemsArchitectural style that guides this organization: the static and dynamic elements and their interfaces, their collaborations, and their composition

Software Architecture Defined

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.

Modeling a Systems Architecture

Architecture and the UML

1. Use Case ViewMajor Elements: use cases Describes: the behavior of systemStakeholders concerned : End Users, analysts, testersDeals with : Values that shape the systems architecture.Refers static aspects : use-case diagrams and dynamic aspects by considering interaction diagrams, state chart diagrams and activity diagrams.Does not specify for organization of a software system.

2. Design View*Major Elements: Classes, Interfaces and CollaborationsDescribes: vocabulary of problem and solution, functional requirements of systemStakeholders concerned : End Users, analysts, design engineersDeals with : services that system provides to its end-usersRefers static aspects :class diagrams +object diagrams and dynamic aspects by considering interaction , state chart and activity diagrams.

3. Process ViewMajor Elements: Active classes that represents threads and processesDescribes: systems concurrency and synchronizationStakeholders concerned : system integratorsDeals with : systems performance, scalability and throughputRefers static and dynamic aspects same as in design view ; with focus on threads and processes.

4. Implementation ViewMajor Elements: Component and FilesStakeholders concerned : ProgrammersDeals with: System assembly, Configuration managementRefers static aspects :component diagrams and dynamic aspects by considering interaction, state chart and activity diagrams.

5. Deployment ViewMajor Elements: NodesStakeholders concerned : System EngineersDeals with: System topology, Distribution, Delivery, InstallationRefers static aspects : deployment diagrams and dynamic aspects by considering interaction, state chart and activity diagrams.

Each of 5 views are independent to support designers to designing process.

UML : modeling languageIt is process-independent, not tied to any particular SDLCTo get most benefits from UML, it should be considered with process that is Use case DrivenArchitecture CentricIterative and Incremental

*Software Development Life Cycle (SDLC)

Use case Driven, Architecture Centric, Iterative and Incremental process is broken into phases.Phase: time-span between two major milestones of the process.Milestone: when well-defined objectives are met, artifacts are completed and decisions made whether to move to next phase.Four Phases of SDLC:InceptionElaborationConstructionTransition

Lifecycle PhasesInceptionElaborationConstructionTransitionInception Define the scope of the project and develop business case Elaboration Plan project, specify features, and baseline the architecture Construction Build the product Transition Transition the product to its users

Software Development Life CyclePrj. ManagementEnvironmentBusiness ModelingImplementationTestAnalysis & DesignPreliminary Iteration(s) Iter. #1PhasesProcess WorkflowsIterationsSupporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1DeploymentConfiguration MgmtRequirementsElaborationTransitionInceptionConstruction

**