Overview of OOMD

Way of thinking about problems using models

Analysis model is built Design decisions are made Details are added Implemented in a programming language OOD refers to indentification and development organization of application domain concepts. OOM is a graphical notation for representing OO concepts.
1

Stages
Stages : Analysis
System design Object design Implementation

Models : Object model

Dynamic model Functional model
2

 Object diagrams : Class diagram

Instance diagram Attributes, Operations and methods links, Assiciations, Multiplicity, role Aggregation, Generalization and Inheritance. Dynamic modelling : State diagram States, events, operations nested state diagrams, concurrency Functional modelling : DFD, Decision tables I/O table of value Equations, Pseudocode 3 Natural Languages

OMT
Analysis System design Object design Implementation : PL, Dbase, Oostyle, Information modelling

Comparison of methodologies
System analysis and system design

Jackson structured development

Introduction to UML

Introduction

Large enterprise applications must be structured to ensure scalability, security and robust execution under stressful conditions. Code Reuse & Debugging Not only large applications but even smaller ones which are highly complex Library of modules and importing the module.
7

The importance of modelling...

The real software cycle ...

1. Programmer produces code he believes is bug-free. 2. Product is tested. 20 bugs are found. 3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs, they're features. 4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs. 5. Repeat three times steps 3 and 4.
9

Why do Software Projects Fail?

Often they are based on solitary, cowboy programmers Bad architecture The wrong tools are used Change was not predicted Change was not controlled The model built was not good

10

Why do software projects succeed?

They have the right people They have the right tools They built the right model

11

What are models for ?

Models capture and precisely state requirements & domain knowledge so that all stakeholders may understand and agree on them. Models help us think about a system. Models capture design decisions and separate them from the requirements. To offree information about large systems. (O=>Organize, F=>Find, F=>Filter, R=>Retrieve, E=>Examine, E=>Edit) To explore multiple solutions economically.
.
12

What is a model ?
A model Is a representation in a certain medium, Captures important aspects of the thing being modeled Simplifies understanding Modeling is designing of software applications before coding. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations) play in the building of a skyscraper.
13

So whats in a model ?
A model essentially has two parts: 1. Semantics 2. Visual Presentation
Semantic aspect captures the meaning of an application as a network of logical constructs such as classes, associations, states, use cases and messages. Visual Presentation shows semantic presentation in a form that can be seen, browsed and edited by humans. They show it in a form directly apprehensible by humans.
14

Prior to UML
Recursive Design Approach Coads lightweight & prototype-oriented approach to methods Class Responsibility Collaboration Object Modeling Technique Information Systems & Information Engineering All the above methods were very similar, yet with minor differences.

15

2.1 Why UML?

Physicists know formal graphical modelling Mathematics to describe nature Feynman graphs to calculate particle reaction rates

We need a common language discuss software systems at a black- (white-) board document software systems UML is an important part of that language UML provides the "words and grammar"

16

What is UML?
UML is an acronym for Unified Modeling Language. Unified Combines the best from existing object-oriented software modeling methodologies. Grady Booch, James Rumbaugh, and Ivor Jacobson are the primary contributors to UML.

17

What is UML?
Modeling Used to present a simplified view of reality in order to facilitate the design and implementation of objectoriented software systems. Language UML is primarily a graphical language that follows a precise syntax.

18

Where did UML come from?

OO modeling languages made their appearance in the late 70s.

As the usefulness of OO programming became undeniable, more OO modeling languages began to appear.
By the start of the 90s there was a flood of modeling languages, each with its own strengths and weaknesses.

19

Where did UML come from?

In 1994 the UML effort officially began as a collaborative effort between Booch and Rumbaugh. Jacobson was soon after included in the effort. The goal of UML is to be a comprehensive modeling language (all things to all people) that will facilitate communication between all members of the development effort.

20

Combining Methodologies

21

Goals
Model systems from concepts to executable artifacts using object-oriented techniques.

Address issues of scale in mission-critical systems

Create a modeling language usable by both human and computers

22

Overview of UML
UML is a language. Conforms to specific rules. Allows the creation of various models. Does not tell the designer which models need to be created. UML is a language for visualizing. UML is a graphical language. Pictures facilitate communication (a picture is worth a thousand words). UML is a language for constructing and understanding. UML supports both forward and reverse engineering.
23

Overview of UML
UML is a language for documenting design
Provides a record of what has been built. Useful for bringing new programmers up to speed. Useful when developing new releases of product.

UML is intended primarily for software-intensive systems

24

Some UML Tools

Visual UML Object Domain Magic Draw UML Rose (Rational) Visual Thought Visio Paradigm Plus Visual CASE ObjecTime UML
25

A Conceptual Model of the UML

A conceptual model needs to be formed by an individual to understand UML. UML contains three types of building blocks: things, relationships, and diagrams. Things Structural things Classes, interfaces, collaborations, use cases, components, and nodes. Behavioral things Messages and states.
26

A Conceptual Model of the UML

Grouping things Packages Annotational things Notes Relationships: dependency, association, generalization and realization.

27

UML Diagrams

Structural Diagrams
Class Diagram, Object Diagram, Component Diagram and Deployment Diagram

Behavior Diagrams
Use Case Diagram, Sequence, Collaboration, Activity, State chart diagrams

28

Structural diagrams
Class diagram model vocabulary of the system and simple interactions Object diagram objects and relationships at a certain point in time Component diagram physical parts of the system Deployment diagram how physical components interact after deployment
29

Class diagram example

30

Object diagram
Objects at a specific point in time
c: Company
d1: Department name = R&D p1: Person ID = 13
31

I: Contact Info phone = 411

Component diagram

32

Deployment diagram
: kiosk deploys user.exe

10-T Ethernet

s: server deploys dbadmin.exe

: RAID farm

c: console deploys config.exe

RS-232

33

Behavioral diagrams
Use case diagram a sample run in detail Sequence diagram emphasizes the time ordering of messages Collaboration diagram emphasizes organization of the objects in interaction State chart diagram finite state machines Activity diagram
34

Use case

35

Sequence diagram

c: Client

: Ticket Agent create setItinerary(i)

route

calculateRoute()

36

State chart diagram

37

Activity diagram

38

Conclusions
UML is a really big set of standards But at least there are tools, and resources on the net UML : a communication tool for you and others UML is not definitively fixed => fill free to add indications if you think it is necessary Keep on your mind : to produce well-formed code, you just need some good sense

39

Software Development Life Cycle

UML is involved in each phase of the software development life cycle.

The UML development process is Use case driven Architecture-centric Iterative and incremental

40

The Top 10 Use Case Modeling Errors

Contrary to the principles we just discussed are a number of common errors that we have seen students make when they're doing use case modeling on their projects for the first time. Our "top 10" list follows. 10. Don't write functional requirements instead of usage scenario text. 9. Don't describe attributes and methods rather than usage. 8. Don't write the use cases too tersely. 7. Don't divorce yourself completely from the user interface. 6. Don't avoid explicit names for your boundary objects. 5. Don't write in the passive voice, using a perspective other than the user's. 4. Don't describe only user interactions; ignore system responses. 3. Don't omit text for alternative courses of action. 2. Don't focus on something other than what is "inside" a use case, such as how you get there or what happens afterward. 1. Don't spend a month deciding whether to use includes or extends.
Source: www.sdmagazine.com

41

Who can benefit from UML?

The UML is of interest to anyone involved in: Software production Software deployment Software testing Software maintenance The UML can be used in: Business modeling Requirements modeling Application modeling Data modeling
42

Rules of UML
Semantic rules - Names (What to call) for elements - Scope (Context) - Visibility (How to use) - Integrity (Relation) - Execution (Run or simulate) - Elided (hidden) - Incomplete (missing) - Inconsistent (not guaranteed) 43

Common mechanisms in UML

Specifications Adornments Common divisions Extensibility mechanisms - Stereotypes
- Tagged values - Constraints
44

Relationships, Setting Multiplicity

Relationship is a connection among things A relationship is rendered as a path Lines on path indicate different kinds of relationships Types : Dependency Generalizations Associations Multiplicity is how many objects may be connected across an instance of an association
45

Dependency has 8 stereotypes

blind Source instantiates target tmplate using
the given actual parameters.

derive Source may be computed from target friend Source is given special visibiliy into the
target

instance of Source object is an instance of the

target classifier
46

 instantiate Source creates instances of the target power type Classifier whose objects are all the

children of a given parent refine Source is at a finer degree of abstraction than the target use The semantics of the source element depends on the semantics of the public part of the targetfor packages access : Source package is granted the right to reference the elements of the target package import : Public contents of target package can enter name space of the source. 47

For Use Cases

extend target use case extends the
behavior of the source

include source use case explicitly

incorporates the behavior of another use case at a location specified by the source

48

For interactions
become target is same object as source but later has different value, state or role call source operation invokes the target operation copy target object is an exact, but independent copy of the source

49

For state machines

send source operation sends the target event

For sub systems

trace target is an historical ancestor of the source

50

Generalization stereotypes
Implementation child inherits implementation of parent but does not make public nor support its interfaces complete all children specified in the model incomplete additionl children are permitted disjoint objects of parent may have no more than one of the children as a type Overlapping objects of parent may have more than one of the children as a type
51

Modelling Reactive objects using state machines

Use state chart diagrams Statechart models behavior of a single object over its lifetime Activity diagram models the flow of control from activity to activity Statechart diagram models flow of control from event to event

52

 Behavior of reactive object

stable states events that trigger transition actions on each state change object creation behavior object destruction life time

Stable states of the object Event occurances : transitions, self and internal

53

Steps
Choose the context for the state machines Choose the initial and final states for the object Decide on stable states Decide on meaningful partial ordering of stable states over the lifetime of the object Decide on triggering events
54

 Attach actions to transitions or to states Simplify your machine using substates, branches, forks, joins and history states Check for reachability of all states Check for dead states Trace through the state machine, either manually or by using tools
55

Reference
G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Addison Wesley, 1999.

56

Created By
Pradeep Kulkarni Preetam Dabade Ruturaj Doshi Chaitra Padasalgi

BE( IT ) IT Department , WIT Solapur

Guided By Prof . LMRJ Lobo sir H.O.D IT Department

57