Updated Uml Aima Final Lecture 23 Apr

Session 1
Introduction to
OOAD and UML
Object Oriented Analysis and Design
Objectives
Discuss the basic concepts of OOA and UML

Discuss the concept and use of UML
Give a whole preview of the elements of
UML, and use simple examples to explain the
function of UML
CDAC (Formerly NCST)
OOAD with UML / Session 1 / 2 of 27

Introduction to UML
Object Oriented
Analysis and Design
(OOA&D)
Object oriented Analysis and Design refers to
the analysis and design of a system based on

the concepts of object orientation.
UML is a diagrammatic approach to model
the software to be developed.

Introduction to UML
SDLC
Software Development Life Cycle (SDLC) is a

sequence of activities carried out by analyst,
designers, and users to develop and
implement an information system.
Analyst Studies requirements
Designer Designs the system
User An entity

Introduction to UML
Object Oriented
Analysis (OOA)
Phase of the project during which a precise

and concise model of the problem in terms
of real world objects and concepts as
understood by the user is developed.
The analysis must also identify the
relevant characteristics, interactions and
relations between the entities.
This kind of real life mapping to computer
analysis is the advantage offered by the
Object Oriented Analysis.

Introduction to UML
Object Oriented Design (OOD)
Programs are organized as co-operative

collections of objects.
The purpose of Object Oriented Design is to
adapt the results of OOA phase.
Designer defines the responsibilities, operations
attributes and relationships of one or several
classes.
Designer also designs the database and applies
normalization techniques.
Diagrams can be classified into static or
dynamic.
Introduction to UML
Advantages of OOA&D over

Traditional Analysis and Design
Close match between what is being implemented and the actual

problem.
Promotes reuse of objects
Since reuse of objects is possible, it reduces errors and
maintenance problems.
Reuse of objects also speeds up the process of design and
development.
Appeals to the working of human cognition, as it is our natural way
of thinking.
Propagates data encapsulation
Helps to handle the complexity of software development and aids
generation of adaptable and resilient software systems.

Introduction to UML
Modeling
A model is a simplification of reality

Provides the blueprints of a system
Models may encompass detailed plans
A good model includes those elements that have broad
abstraction.
Helps to visualize a system as it is or according to the
need.
Models permit to specify the structure or behavior of a
system.
Models give a template that guides in constructing a
system.
Models document the decisions that have been made
Introduction to UML
SDLC Phases-1

Introduction to UML
SDLC Phases-2
Preliminary Investigation (Feasibility Study)

An important outcome of the preliminary investigation is
determining whether the system to be developed is feasible
or not.
Requirement Analysis (Analysis)

Involves study of the current business system in detail and to
find out how it works and where the improvements have to
be made.

Introduction to UML
10
SDLC Phases-4
Design of the System

The design phase states how a system will meet the requirements
identified during the systems analysis phase as mentioned in the
Requirements Specifications.
Identification of data entry forms, data elements, reports, outputs
the new system should produce, data elements and tables for
database.
Sketch the form or display as expected to appear at the end of
completion of the system.
Computation procedures explaining the process of deriving the
output from given input.

Introduction to UML
11
SDLC Phases-6
Software Construction
Actual construction (coding) of the programs
System Testing
Actual software code construction
Unit Testing: White Box testing
Independent Unit Testing

Introduction to UML
12
SDLC Phases-8
System Testing
After the programs are tested individually, the system as a whole
needs to be tested.
All the software modules are integrated and tested to ensure that
they do not fail i.e. it will run according to specifications as
mentioned in requirement specification document and in the way
the users expected it to.
Special test data is prepared as input for processing and the
results are examined to find out any deviations from the desired
results.

Introduction to UML
13
SDLC Phases-9
System Implementation
Developed system is deployed at the users site for use
User personnel are trained
The data files needed by the system are constructed
System Maintenance
Due to environmental changes, the software may turn obsolete and it may
call for modifications and enhancements for its effective use.
The activity of system maintenance may vary depending on the scale of
modifications and enhancements.

Introduction to UML
14
Model
The language used to represent a model is called a

Modeling Language.
Object Model can be explained as a model to represent
objects of a system.
Principle of Model Creation
The choice of what models to create has a profound influence on

how a problem is attacked and how a solution is shaped.
No single model is sufficient.

Introduction to UML
15
Object Oriented Model Creation
The contemporary view of software

development is an object-oriented perspective.
In this approach the main building block of all
software systems is the object or class.

Introduction to UML
16
Introduction to UML
Some of the leading companies that have

contributed towards and promoted the
development of UML are
Hewlett Packard
Microsoft
Oracle
IBM
Unisys

Introduction to UML
17
Application in Software
Development Life Cycle
Preliminary Investigation: Use Cases to capture the

requirements of a customer.
Analysis: Class diagrams are made at real world abstract
level to depict their existence and relationship.
Design: Classes are modeled
Development: Programmers refer to the various UML
diagrams prepared in the design stage to understand and
develop code.
Testing: UML has different diagrams to support testing of
software.

Introduction to UML
18
UML Overview
Views- would mean to observe or to examine

Diagrams- is a part of a specific view and when it is
drawn it is allocated to a view.
Relationships-provide a pathway for communication
between objects.
Modeling Elements-consist of symbols that help in
preparing diagrams and views.

Introduction to UML
19
4+1 view

Introduction to UML
20
UML Hello World

Introduction to UML
21
Component
Source code components (e.g., .h, .cpp files, shell

scripts, data files)
Binary code components. Examples include: java
Beans, ActiveX controls, COM objects (DLLs and
OCXs from VB), CORBA objects)
Executable components (.exes)
Stereotypes (with alternatives icons) may be used to
define these specific kinds of components.

Introduction to UML
22
Summary
UML is a modeling tool

Various Diagrams of UML are used to model a system
UML is used many areas of applications
UML is used in all the phases of SDLC
The 4+1 view architectural model is a simplified description
(an abstraction) of a system from a particular perspective or
vantage point, covering particular concerns, and omitting
entities that are not relevant to this perspective.
Different parts of UML are
Views
Diagrams
Relationships
Model Elements

Introduction to UML
23
UML:
An Introduction
Contents
Why model ?
Principles of modeling
What is UML ?
Conceptual Model of the UML

Building Blocks
Rules
Common Mechanisms
Introduction to UML
25
Why Model ?
Analyse the problem-domain

simplify reality
capture requirements
visualize the system in its entirety
specify the structure and/or behaviour of the
system
Design the solution

document the solution - in terms of its
structure, behaviour, etc.
Introduction to UML
26
Principles of Modeling
Choose your model well - the choice of model profoundly

impacts the analysis of the problem and the design of the solution.
Every model may be expressed at different levels

of precision - the same model can be scaled up (or down) to
different granularities.
The best models are connected to reality - simplify

the model, but dont hide important details.
No single model suffices - every nontrivial system has

different dimensions to the problem and its solution.
Introduction to UML
27
What is UML ?
UML - Unified Modeling language
UML is a modeling language, not a methodology

or process
Developed by Grady Booch, James Rumbaugh

and Ivar Jacobson at Rational Software.
Accepted as a standard by the Object

Management Group (OMG), in 1997.
Introduction to UML
28
What is UML?
A standardized, graphical modeling language for

communicating software design.
Allows implementation-independent specification of:
user/system interactions (required behaviors)
partitioning of responsibility (OO)
integration with larger or existing systems
data flow and dependency
operation orderings (algorithms)
concurrent operations
Pretty pictures.
UML is not process. (That is, it doesnt tell you how to do
things, only what you should do.)
29
Introduction to UML
29
Motivations for UML
UML is a fusion of ideas from several precursor

modeling languages.
We need a modeling language to:
help develop efficient, effective and correct
designs, particularly Object Oriented designs.
communicate clearly with project
stakeholders (concerned parties: developers,
customer, etc).
give us the big picture view of the project.
30
Introduction to UML
30
Structural Things
The nouns of UML models; usually the static
parts of the system in question.
Class - an abstraction of a set of things in the problemdomain that have similar properties and/or functionality.
Notation:
customer
Interface - a collection of operations that specify the

services rendered by a class or component.
Notation:
Introduction to UML
31
Structural Things (contd.)
Collaboration - a collection of UML building blocks

(classes, interfaces, relationships) that work together to
provide some functionality within the system.
Notation:
Accounts
System
Use Case - an abstraction of a set of functions that the

system performs; a use case is realized by a collaboration.
Notation:
Process
Order
Introduction to UML
32
Active Class - a class whose instance is an active object; an

active object is an object that owns a process or thread (units of
execution)
Notation:
eventManager
Component - a physical part (typically manifests itself as

a piece of software) of the system.
Notation:
DML_Parser.C
Introduction to UML
33
Node - a physical element that exists at run-time and

represents a computational resource (typically, hardware
resources).
Notation:
PrintServer
Introduction to UML
34
Behavioral Things
The verbs of UML models; usually the dynamic
parts of the system in question.
Interaction - some behaviour constituted by messages

exchanged among objects; the exchange of messages is with a
view to achieving some purpose.
Notation:
Parse
Introduction to UML
35
Behavioral Things (contd.)
State machine - a behaviour that specifies the sequence

of states an object goes through, during its lifetime. A
state is a condition or situation during the lifetime of an
object during which it exhibits certain characteristics and/or
performs some function.
Notation:
Engine
Idling
Introduction to UML
36
Grouping Things
The organisational part of the UML model; provides a
higher level of abstraction (granularity).
Package - a general-purpose element that comprises UML

elements - structural, behavioral or even grouping things.
Packages are conceptual groupings of the system and need
not necessarily be implemented as cohesive software modules.
.
Notation:
Accounts
Department
Introduction to UML
37
Annotational Things
The explanatory part of the UML model; adds
information/meaning to the model elements.
Note - a graphical notation for attaching constraints and/or

comments to elements of the model.
Notation:
Parses userquery and builds

expression stack
(or invokes
ErrorHandler)
Introduction to UML
38
Relationships
Articulates the meaning of the links between things.
Dependency - a semantic relationship where a change in

one thing (the independent thing) causes a change in the
semantics of the other thing (the dependent thing).
Notation:
(arrow-head points to the independent thing)
Association - a structural relationship that describes the

connection between two things.
Notation:
Introduction to UML
39
Relationships (contd.)
Generalisation - a relationship between a general thing

(called parent or superclass) and a more specific kind of
that thing (called the child or subclass), such that the
latter can substitute the former.
Notation:
(arrow-head points to the superclass)
Introduction to UML
40
Relationships (contd.)
Realization - a semantic relationship between two things

wherein one specifies the behaviour to be carried out, and
the other carries out the behaviour.
a collaboration realizes a Use Case

the Use Case specifies the behaviour (functionality)
to be carried out (provided), and the collaboration
actually implements that behaviour.
Notation:
(arrow-head points to the thing being

realized)
Introduction to UML
41
Diagrams
The graphical presentation of the model. Represented
as a connected graph - vertices (things) connected by
arcs (relationships).
UML includes nine diagrams - each capturing a
different dimension of a software-system architecture.
Class Diagram
Object Diagram
Use Case Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployment Diagram
Introduction to UML
42
More on Diagrams...
Class Diagram - the most common diagram found in

OOAD, shows a set of classes, interfaces, collaborations and
their relationships. Models the static view of the system.
Object Diagram - a snapshot of a class diagram; models

the instances of things contained in a class diagram.
Use Case Diagram - shows a set of Use Cases (sets

of functionality performed by the system), the actors
(typically, people/systems that interact with this
system[problem-domain]) and their relationships. Models
WHAT the system is expected to do.
Introduction to UML
43
More on Diagrams...
Sequence Diagram - models the flow of control by timeordering; depicts the interaction between various objects by
of messages passed, with a temporal dimension to it.
Collaboration Diagram - models the interaction

between objects, without the temporal dimension; merely
depicts the messages passed between objects.
Statechart Diagram - shows the different state machines

and the events that leads to each of these state machines.
Statechart diagrams show the flow of control from state to
state.
Introduction to UML
44
More on Diagrams...
Activity Diagram - shows the flow from activity to

activity; an activity is an ongoing non-atomic execution
within a state machine.
Component Diagram - shows the physical packaging

of software in terms of components and the dependencies
between them.
Deployment Diagram - shows the configuration of the

processing nodes at run-time and the components that live on
them.
Introduction to UML
45
Dimensions...
. . .of Software Architecture
Structural Implementation
View View
Class Diagrams
Object Diagrams
Component Diagrams
User View
Use Case
Diagrams
Sequence Diagrams
Deployment Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
Behavioral Environment
View View
Introduction to UML
46
Rules
Specify what a well-formed model should

look like.
The UML has semantic rules for

Names
Scope
Visibility
Integrity
Execution
Introduction to UML
47
Common Mechanisms
Mechanisms/elements that apply consistently

throughout the language:
Specifications
Adornments (Notes)
Common Divisions
Extensibility Mechanisms
Stereotypes
Tagged values
Constraints
Introduction to UML
48
Adornments
Adorn the model - i.e., enhance the model. Adds to
the meaning and/or semantics of the element to
which it pertains.
Notes are the mechanism provided by UML for
adorning a model:
graphical symbol to render constraints, comments, etc.
a note that renders only a comment has no semantic

impact on the element it is adorning; at most adds
meaning to it and/or provides guidelines for
implementation.
Introduction to UML
49
UML syntax, 2
Arrows: arrows indicate all manner of things,

depending on which particular type of UML
diagram theyre in. Usually, arrows indicate
flow, dependency, association or generalization.
Cardinality: applied to arrows, cardinalities
show relative numerical relationships between
elements in a model: 1 to 1, 1 to many, etc.
50
Introduction to UML
50
UML syntax, 3
Constraints: allow notation of arbitrary constraints on

model elements. Used, for example, to constrain the
value of a class attribute (a piece of data).
Stereotypes: allow us to extend the semantics of UML
with English. A stereotype is usually a word or short
phrase that describes what a diagram element does.
That is, we mark an element with a word that will
remind us of a common (stereotypical) role for that sort
of thing. Stereotypes should always be applied
consistently (with the same intended meaning in all
instances).
51
Introduction to UML
51
UML diagrams: use cases
A use case encodes a typical user interaction with the

system. In particular, it:
captures some user-visible function.
achieves some concrete goal for the user.
A complete set of use cases largely defines the

requirements for your system: everything the user can
see, and would like to do.
A use case maps actors to functions. The actors need
not be people.
52
Introduction to UML
52
Use case examples, 1

(High-level use case for powerpoint.)
53
Introduction to UML
53
About the last example...
Although this is a valid use case for powerpoint,

and it completely captures user interaction with
powerpoint, its too vague to be useful.
54
Introduction to UML
54

(Finer-grained use cases for powerpoint.)
55
Introduction to UML
55
The last example gives a more useful view of

powerpoint (or any similar application).
The cases are vague, but they focus your attention
the key features, and would help in developing a
more detailed requirements specification.
It still doesnt give enough information to
characterize powerpoint, which could be specified
with tens or hundreds of use cases (though doing
so might not be very useful either).
56
Introduction to UML
56

(Relationships in a news web site.)
57
Introduction to UML
57
The last is more complicated and realistic use case

diagram. It captures several key use cases for the
system.
Note the multiple actors. In particular, AP wire is an
actor, with an important interaction with the system, but
is not a person (or even a computer system,
necessarily).
The notes between << >> marks are stereotypes:
identifiers added to make the diagram more informative.
Here they differentiate between different roles (ie,
different meanings of an arrow in this diagram).
58
Introduction to UML
58
UML in your documents
UML is intended to ease the task of

communicating software designs.
Typical uses of UML in G64HLL:
conceptual component diagrams in the
concept document.
use cases and class diagrams in the
requirements document.
class, sequence, state, package and
deployment diagrams in the architecture
document.
59
Introduction to UML
59
UML pitfalls, 1
UML is a language, with a (reasonably) rigorous

syntax and accepted semantics; that is, the
diagrams have a meaning. Thus you have to be
careful that the meaning of your diagram is what
you intended.
However, the semantics of UML are less welldefined than a programming language (where the
semantics are defined by the compiler). Thus
there is some leeway to use UML your own way:
but you must be consistent in what you mean by
the things you draw.
60
Introduction to UML
60
UML diagrams: class

diagram
Motivated by Object-Oriented design and
programming (OOD, OOP).

A class diagram partitions the system into areas
of responsibility (classes), and shows
associations (dependencies) between them.
Attributes (data), operations (methods),
constraints, part-of (navigability) and type-of
(inheritance) relationships, access, and
cardinality (1 to many) may all be noted.
61
Introduction to UML
61
Class diagram
perspective
Class diagrams can make sense at three distinct
levels, or perspectives:
Conceptual: the diagram represents the concepts in the

project domain. That is, it is a partitioning of the relevant
roles and responsibilities in the domain.
Specification: shows interfaces between components in
the software. Interfaces are independent of
implementation.
Implementation: shows classes that correspond directly
to computer code (often Java or C++ classes). Serves as
a blueprint for an actual realization of the software in
code.
62
Introduction to UML
62
Class diagram examples

(A classroom scheduling system: specification perspective.)
63
Introduction to UML
63
Each box is a class, with necessary attributes

and operations specified.
Navigability arrows show which classes can
reference which others.
Cardinality marked in bi-directional manner on
arrows.
The classes together represent the complete
system; thus the the classes are a partitioning
of the system.
64
Introduction to UML
64
What is a Class Diagram?
A class diagram is a view of the static structure

of a system
Models contain many class diagrams
Class diagrams contain:

Packages, classes, interfaces, and relationships
Notation:
Package
Name
Class Name
<<Interface>>
Interface Name
65
Introduction to UML
65
Relationships
Class diagrams may contain the following

relationships:
Association, aggregation, dependency, realize, and
inheritance
Notation:
Association
Aggregation
Inheritance
Dependency
Realize
66
Introduction to UML
66
About the next 2 slides

The next slide shows a package diagram,
with dependencies.
The following slide shows a class diagram,
with various associations between the
classes.
67
Introduction to UML
67
Package Relationships
68
Introduction to UML
68
Multiplicity Indicators
Each end of an association or aggregation

contains a multiplicity indicator
Indicates the number of objects participating in the
relationship
1
Exactly one
0..*
Zero or more
1..*
One or more
0..1
Zero or one
2..7
Specified range
69
Introduction to UML
69
Multiplicity Indicators
70
Introduction to UML
70
Sequence Diagrams
71
UML diagrams: sequence

Sequence diagram describe algorithms, though usually at a
diagram
high level: the operations in a useful sequence diagram
specify the message passing (method invocation)

between objects (classes, roles) in the system.
The notation is based on each objects life span, with
message passing marked in time-order between the
objects. Iteration and conditional operations may be
specified.
May in principle be used at the same three levels as class
diagrams, though the specification level will usually be most
useful. (At the implementation level, you might better use
pseudocode.)
72
Introduction to UML
72
Sequence diagram
example
73
Introduction to UML
73
More on UML...
UML is a modeling language for visualising,
specifying, constructing and documenting the
artifacts(pieces) of software systems.
Visualising - a picture is worth a thousand
words; a graphical unambiguously
communicates the overall view of the system
(problem-domain).
Introduction to UML
74
UML diagrams: Package

diagram
A type of class diagram, package diagrams show
dependencies between high-level system component.

A package is usually a collection of related classes,
and will usually be specified by its own class diagram.
The software in two distinct packages is separate;
packages only interact through well-defined interfaces,
there is no direct sharing of data or code.
Not all packages in a systems package diagram are
new software; many packages (components) in a
complex system are often already available as existing
or off-the-shelf software.
75
Introduction to UML
75
Package diagram example
76
Introduction to UML
76
This package diagram indicates that:

there are three dependent but decoupled software
components that will be developed in My Project,
which is itself a package or component.
Parts of my software depend on some existing
software packages, which I wont be developing, but
just using (Webserver and Database).
There is a globally available package User
authentication which all the other packages depend
on.
77
Introduction to UML
77
About the next slide
The next slide shows a complete deployment

diagram.
A deployment diagram is useful for showing how
your software will be deployed on hardware. It
may show how your system will integrate with
existing systems in the domain.
78
Introduction to UML
78
Exercise: Deployment Diagram
79
Introduction to UML
79
More on UML...
Specifying - UML provides the means to model
precisely, unambiguously and completely, the
system in question.
Constructing - models built with UML

have a design dimension to it; these are
language independent and can be
implemented in any programming language.
Introduction to UML
80
More on UML...
Documenting - every software
project involves a lot of documentation from the inception phase to the
deliverables.
Documentation is
(among others) for:
Requirements
Design
Tests
UML provides the

notations for
documenting some
of these artifacts
Introduction to UML
81
Stereotypes
Used to create new building blocks from

existing blocks.
New building blocks are domain-specific.
A particular abstraction is marked as a

stereotype and this stereotype is then used at
other places in the model to denote the
associated abstraction.
Notation: metaclass
Introduction to UML
82
Tagged Values
Used to add to the information of the element

(not of its instances).
Stereotypes help create new building blocks;

tagged values help create new attributes.
Commonly used to specify information relevant

to code generation, configuration management,
etc.
Notation: {version=1.4}
Introduction to UML
83
Constraints
Used to create rules for the model.
Rules that impact the semantics of the model,

and specify conditions that must be met.
Can apply to any element in the model attributes of a class, relationship, etc.
Notation: { incomplete, disjoint }
Introduction to UML
84
Summary
Modeling captures the system in its entirety, along with

the different dimensions of its complexity.
Facilitates quick and efficient analysis and design and

helps communicate the overall system architecture
unambiguously.
Principles of modeling lay down that:

model must be chosen well
model should encapsulate different granularities
models can make simplifying assumptions, but not
hide important facts
no single model can capture all dimensions of the
complexity
Introduction to UML
85
Summary
UML (Unified Modeling Language) is a language that

helps analyse and design solutions for softwareintensive systems
Developed by Booch, Rumbaugh and Jacobson at

Rational Software; subsequently adopted as an open
standard by the Object Management Group in 1997.
UML is a modeling language for visualising, specifying,

constructing and documenting the artifacts of a
software system.
It is a modeling language and not a methodology or a

process.
Introduction to UML
86
Summary
The conceptual model of the UML comprises the

Building Blocks of UML, its Rules and certain
Common Mechanisms that are applicable across the
entire language.
The Building Blocks comprise Things, Relationships

and Diagrams.
Things are of grouped into 4 categories: structural

things, behavioral things, grouping things and
annotational things.
Introduction to UML
87
Summary
Structural things describe the static part of the model and

are of seven types: class, interface, collaboration, use
case, active class, component, node.
Behavioral things describe the dynamic part of the model

and are of two types: interaction and state machine.
Packages are included under Grouping things, and

Notes under Annotational things
Relationships link things to each other and are of four

types: Dependency, Association, Generalisation and
Realization.
Introduction to UML
88
Summary
Diagrams are essentially connected graphs - a set of

vertices (things) connected by arcs (relationships). There
are several types of diagrams, each one capturing a
different dimension of the systems complexity.
Diagrams are of nine types: Class Diagram, Object

Diagram, Use Case Diagram, Sequence Diagram,
Collaboration Diagram, Statechart Diagram, Activity
Diagram, Implementation Diagram, Deployment Diagram.
The UML has semantic rules for Names of classifiers,

Scope of these names, Visibility of these names, and the
Integrity and Execution of the model.
Introduction to UML
89
Summary
Certain common mechanisms apply uniformly across the

model. There are four such mechanisms: Specifications,
Common Divisions, Adornments, Extensibility Mechanisms.
Notes are the most common adornments used, that add

to the meaning of a classifier.
Extensibility mechanisms include Stereotypes, Tagged

values and constraints.
Introduction to UML
90
References
The Unified Modeling Language User
Guide
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison-Wesley (International Student Edition)
UML Distilled
Martin Fowler (with Kendall Scott)
Addison-Wesley
Model Elements
Class
Use case
name
Component Name
Attributes
Operations
Dependency
Generalization
Association
Aggregation
(a form of Association)

Introduction to UML
92
UML in Brief
Use-Case diagrams to illustrate user interactions with the

system.
Class diagrams to illustrate logical structure
Object diagrams to illustrate objects and links
State diagrams to illustrate behavior
Component diagrams to illustrate physical structure of the
software.
Deployment diagrams to show the mapping of software to
hardware configuration
Interaction diagram (i.e., collaboration and sequence
diagrams) to illustrate behavior.
Activity diagrams to illustrate the flow of events in a UseCase.

Introduction to UML
93

Updated Uml Aima Final Lecture 23 Apr

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Updated Uml Aima Final Lecture 23 Apr

Transféré par

Droits d'auteur :

Formats disponibles

Session 1

Object Oriented Analysis and Design

Discuss the basic concepts of OOA and UML

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 2 of 27

Object Oriented Analysis and Design

the analysis and design of a system based on

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 3 of 27

Object Oriented Analysis and Design

Software Development Life Cycle (SDLC) is a

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 4 of 27

Object Oriented Analysis and Design

Phase of the project during which a precise

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 5 of 27

Object Oriented Analysis and Design

Object Oriented Design (OOD)

Programs are organized as co-operative

CDAC (Formerly NCST)

Object Oriented Analysis and Design

Advantages of OOA&D over

Close match between what is being implemented and the actual

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 7 of 27

Object Oriented Analysis and Design

A model is a simplification of reality

CDAC (Formerly NCST)

Object Oriented Analysis and Design

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 9 of 27

Object Oriented Analysis and Design

Preliminary Investigation (Feasibility Study)

Requirement Analysis (Analysis)

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 10 of 27

Object Oriented Analysis and Design

Design of the System

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 11 of 27

Object Oriented Analysis and Design

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 12 of 27

Object Oriented Analysis and Design

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 13 of 27

Object Oriented Analysis and Design

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 14 of 27

Object Oriented Analysis and Design

The language used to represent a model is called a

Principle of Model Creation

The choice of what models to create has a profound influence on

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 15 of 27

Object Oriented Analysis and Design

Object Oriented Model Creation

The contemporary view of software

CDAC (Formerly NCST)

OOAD with UML / Session 1 / 16 of 27

Object Oriented Analysis and Design

Some of the leading companies that have