Modelling and UML

8/2/2019 Modelling and UML

1/57

Modeling and UML


2/57

The roots of UML The development of UML began in late 1994 when

Grady Booch and Jim Rumbaugh of RationalSoftware Corporation began their work on

unifying the Booch and OMT (Object ModelingTechnique) methods. In the Fall of 1995, IvarJacobson and his Objectory company joinedRational and this unification effort, merging inthe OOSE (Object-Oriented SoftwareEngineering) method.1


3/57

Why unify? These methods were already evolving toward each otherindependently. It made sense to continue that evolution togetherrather than apart, eliminating the potential for any unnecessaryand gratuitous differences that would further confuse users.

By unifying the semantics and notation, they could bring somestability to the object-oriented marketplace, allowing projects tosettle on one mature modeling language and letting tool buildersfocus on delivering more useful features.

They expected that their collaboration would yield improvementsin all three earlier methods, helping them to capture lessons

learned and to address problems that none of their methodspreviously handled well.1


4/57

OMT -The object-modeling technique (OMT)is an object modeling language for

software modeling and designing. Itwas developed circa 1991 byRumbaugh, as a method to developobject-oriented systems, and tosupport object-orientedprogramming.
http://en.wikipedia.org/wiki/Object_modeling_languagehttp://en.wikipedia.org/wiki/Computer_softwarehttp://en.wikipedia.org/wiki/James_Rumbaughhttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/James_Rumbaughhttp://en.wikipedia.org/wiki/Computer_softwarehttp://en.wikipedia.org/wiki/Object_modeling_language


5/57

The three OMT Models Object model: The object model represents the static and most stablephenomena in the modeled domain [3]. Main concepts are classes andassociations, with attributes and operations. Aggregation andgeneralization (with multiple inheritance) are predefined relationships.[2]

Dynamic model: The dynamic model represents a state/transition view on

the model. Main concepts are states, transitions between states, andevents to trigger transitions. Actions can be modeled as occurring withinstates. Generalization and aggregation (concur-rency) are predefinedrelationships.[2]

Functional model: The functional model handles the process perspective ofthe model, corresponding roughly to data flow diagrams. Main concepts are

process, data store, data flow, and actors.[2]


6/57

BoochThe Booch method is a technique usedin software engineering. It is an

object modeling language andmethodology that was widely used inobject-oriented analysis and design.It was developed by Grady Booch,while at Rational Software Booch'smethodology has its primary strengthin the object system design.
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Object_modeling_languagehttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Object_modeling_languagehttp://en.wikipedia.org/wiki/Software_engineering


7/57

Booch Method - AnalysisThe analysis phase is split into steps.The first step is to establish the requirements from the customerperspective. This analysis step generates a high-level description of thesystem's function and structure.

The second step is a domain analysis. The domain analysis is accomplishedby defining object classes; their attributes, inheritance, and methods.State diagrams for the objects are then established.

The analysis phase is completed with a validation step. The analysis phaseiterates between 1 and 2.


8/57

Booch Method - DesignThe design phase is iterative. A logic design ismapped to a physical design where details ofexecution threads, processes, performance,

location, data types, data structures, visibility,and distribution are established. A prototype iscreated and tested. The process iterates betweenthe logical design, physical design, prototypes, andtesting.


9/57

OOSE Object-Oriented Software Engineering (OOSE) is

a software design technique that is used insoftware design in object-oriented programming.

OOSE is developed by Ivar Jacobson in 1992.OOSE is the first object-oriented designmethodology that employs use cases in softwaredesign.

It includes a requirements, an analysis, a design,an implementation and a testing model.


10/57


11/57

What is a ModelA model is a simplification of reality


12/57

What does a model doA good model includes those elements that havebroad effect and omits those minor elements thatare not relevant to the given level of abstraction.Every system may be described from different

aspects using different models, and each model istherefore a semantically closed abstraction ofthe system.A model may be structural, emphasizing theorganization of the system, or it may be

behavioral, emphasizing the dynamics of thesystem.


13/57

Modeling achieves four

aims Models help us to visualize a system as itis or as we want it to be (divide andconquer).

Models permit us to specify thestructure or behavior of a system. Models give us a template that guides us

in constructing a system.

Models document the decisions we havemade.


14/57

Four basic principles of

modeling. The choice of what models to create has a profoundinfluence on how a problem is attacked and how asolution is shaped.

Database developer, will likely focus on entity-relationshipmodels that push behavior into triggers and stored

procedures. A structured analyst, will likely end up with models that are

algorithmic-centric, with data flowing from process toprocess.

If you build a system through the eyes of an object-oriented developer, you'll end up with a system whosearchitecture is centered around a sea of classes and the

patterns of interaction that direct how those classes worktogether.


15/57

Every model may be expressed atdifferent levels of precision.

Sometimes, a quick and simple executable

model of the user interface is exactlywhat you need; at other times, you have toget down and dirty with the bits, such aswhen you are specifying cross-system

interfaces or wrestling with networkingbottlenecks.


16/57

The best models are connected toreality.

All models simplify reality; the trick is tobe sure that your simplifications don'tmask any important details.

In object-oriented systems, it is possible

to connect all the nearly independent viewsof a system into one semantic whole.


17/57

No single model is sufficient. Everynontrivial system is best approachedthrough a small set of nearly

independent models.

Models can be built and studiedseparately but that are still

interrelated.


18/57

Depending on the nature of the system, somemodels may be more important than others. Forexample, in data-intensive systems, modelsaddressing static design views will dominate. In

GUI-intensive systems, static and dynamic usecase views are quite important. In hard real timesystems, dynamic process views tend to be moreimportant. Finally, in distributed systems, such asone finds in Web-intensive applications,implementation and deployment models are themost important.


19/57

Algorithmic ApproachThe traditional view of softwaredevelopment takes an algorithmicperspective. In this approach, the main

building block of all software is theprocedure or function. This view leadsdevelopers to focus on issues of controland the decomposition of larger algorithmsinto smaller ones. As requirements change

and the system grows systems built withan algorithmic focus turn out to be veryhard to maintain.


20/57

Object-oriented

perspectiveThe main building block of all softwaresystems is the object or class. An objectis a thing, generally drawn from the

vocabulary of the problem space or thesolution space; a class is a description of aset of common objects. An obj hasi) identityii) stateiii)behavior


21/57

Why OO The object-oriented approach to

software development is decidedly a

part of the mainstream simplybecause it has proven to be of valuein building systems in all sorts ofproblem domains and encompassing alldegrees of size and complexity.


22/57

UML Basics A language provides a vocabulary and the rules forcombining words in that vocabulary for thepurpose of communication. A modelinglanguage isa language whose vocabulary and rules focus on

the conceptual and physical representation of asystem. The Unified Modeling Language (UML) is a

standard language for writing softwareblueprints. The UML may be used to visualize,

specify, construct, and document the artifacts ofa software-intensive system.


23/57

The UML Is a Language forVisualizing

UML facilitates communication.

The UML is graphical language.

One developer can write a model inthe UML, and another developer, oreven another tool, can interpret that

model unambiguously.


24/57

The UML Is a Language

for SpecifyingIn this context, specifyingmeans buildingmodels that are precise, unambiguous, and

complete. In particular, the UMLaddresses the specification of all theimportant analysis, design, andimplementation decisions that must be

made in developing and deploying asoftware-intensive system.


25/57

The UML Is a Language forConstructing

The UML is not a visual programming language, butits models can be directly connected to a varietyof programming languages. This means that it ispossible to map from a model in the UML to aprogramming language such as Java, C++, or VisualBasic, or even to tables in a relational database orThings that are best expressed graphically aredone so graphically in the UML, whereas thingsthat are best expressed textually are done so inthe programming language.


26/57

The UML Is a Language forDocumenting

A healthy software organization produces allsorts of artifacts in addition to raw executablecode. These artifacts include (but are not limitedto)

Requirements,Architecture,Design,Sourcecode,Project plans,Tests,Prototypes,Releases

Such artifacts are not only the deliverables of aproject, they are also critical in controlling,

measuring, and communicating about a systemduring its development and after its deployment.


27/57

Building Blocks of the UML The vocabulary of the UML encompassesthree kinds of building blocks:Things

RelationshipsDiagramsThings are the abstractions; relationships

tie these things together; diagrams groupinteresting collections of things.


28/57

Things in the UML There are four kinds of things in the

UML:

Structural thingsBehavioral things

Grouping things

Annotational things


29/57

Structural things The nouns of UML models. These are

the mostly static parts of a model,

representing elements that areeither conceptual or physical. In all,there are seven kinds of structuralthings.


30/57

Types of structural

things Classes

Interfaces

Collaborations Use cases

Active classes

Components Nodes


31/57

Behavioral Things Behavioral things are the dynamic parts of

UML models. These are the verbs of amodel, representing behavior over time

and space. In all, there are two primarykinds of behavioral things.

interaction

state machine


32/57

Grouping ThingsGrouping things are the organizationalparts of UML models. These are the boxesinto which a model can be decomposed. In

all, there is one primary kind of groupingthing

Packages


33/57

Annotational ThingsAnnotational thingsare the explanatoryparts of UML models. These are thecomments you may apply to describe,

illuminate, and remark about any elementin a model. There is one primary kind ofannotational thing, called a note.

note


34/57

Relationships in the UML

There are four kinds of relationshipsin the UML:

DependencyAssociation

Generalization

Realization


35/57

Diagrams in the UML Class diagram Object diagram Use case diagram

Sequence diagram Collaboration diagram Statechart diagram Activity diagram

Component diagram Deployment diagram


36/57

Structural things :

Classes First, a classis a description of a setof objects that share the sameattributes, operations, relationships,and semantics. A class implementsone or more interfaces. Graphically, aclass is rendered as a rectangle,

usually including its name, attributes,and operations


37/57


38/57

Structural things :

InterfacesAn interfaceis a collection of operations thatspecify a service of a class or component. Aninterface might represent the complete behaviorof a class or component or only a part of that

behavior. An interface defines a set of operationspecifications (that is, their signatures) but nevera set of operation implementations. Graphically, aninterface is rendered as a circle together with itsname. An interface rarely stands alone. Rather, itis typically attached to the class or componentthat realizes the interface


39/57


40/57

Structural things

:Collabrations collaborationdefines an interaction and isa society of roles and other elements thatwork together to provide some cooperativebehavior that's bigger than the sum of allthe elements. Therefore, collaborationshave structural, as well as behavioral,dimensions. A given class might participatein several collaborations. Graphically, a

collaboration is rendered as an ellipse withdashed lines, usually including only its name


41/57


42/57

Structural things :Use

Caseuse caseis a description of set ofsequence of actions that a system

performs that yields an observableresult of value to a particular actor.A use case is used to structure thebehavioral


43/57


44/57

Structural things :Active

ClassAn active classis a class whose objectsown one or more processes or threads andtherefore can initiate control activity. Anactive class is just like a class except thatits objects represent elements whosebehavior is concurrent with otherelements. Graphically, an active class isrendered just like a class, but with heavy

lines, usually including its name, attributes,and operations


45/57


46/57

Structural things

(Physical) :Componentsa componentis a physical and replaceable part of asystem that conforms to and provides therealization of a set of interfaces. In a system,

you'll encounter different kinds of deployment

components, such as COM+ components or JavaBeans, as well as components that are artifacts ofthe development process, such as source codefiles. A component typically represents thephysical packaging of otherwise logical elements,such as classes, interfaces, and collaborations.

Graphically, a component is rendered as arectangle with tabs, usually including only its name


47/57


48/57

Structural things

(Physical) :NodeA nodeis a physical element that exists atrun time and represents a computationalresource, generally having at least some

memory and, often, processing capability.A set of components may reside on a nodeand may also migrate from node to node.Graphically, a node is rendered as a cube,usually including only its name


49/57


50/57

Behavioral things

:InteractionAn interactionis a behavior that comprises a setof messages exchanged among a set of objectswithin a particular context to accomplish aspecific purpose. An interaction involves a number

of other elements, including messages, actionsequences (the behavior invoked by a message),and links (the connection between objects).Graphically, a message is rendered as a directedline, almost always including the name of itsoperation


51/57


52/57

Behavioral things :State

Machinestate machineis a behavior that specifies thesequences of states an object or an interactiongoes through during its lifetime in response to

events, together with its responses to thoseevents. The behavior of an individual class or acollaboration of classes may be specified with astate machine. A state machine involves a numberof other elements, including states, transitions

,events, and activities. Graphically, a state isrendered as a rounded rectangle, usually includingits name and its substates, if any


53/57


54/57

Grouping things : PackageApackageis a general-purpose mechanismfor organizing elements into groups.Structural things, behavioral things, andeven other grouping things may be placedin a package. Unlike components (whichexist at run time), a package is purelyconceptual (meaning that it exists only at

development time). Graphically, a packageis rendered as a tabbed folder, usuallyincluding only its name and, sometimes, itscontents


55/57

l h


56/57

Annotational things :

NoteAnnotational thingsare theexplanatory parts of UML models.

These are the comments you mayapply to describe, illuminate, andremark about any element in a model.There is one primary kind of

annotational thing, called a note.


57/57

Date post:	05-Apr-2018
Category:	Documents
Upload:	suhrid-banerjee
View:	219 times
Download:	0 times

Modelling and UML

Documents