Scribd
Upload
12 views12 pages

OOAD Unit-II

uml class diagrams

Uploaded by

M Madhavi Asst. Professor, CSE, VRSEC
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
12 views12 pages

OOAD Unit-II

uml class diagrams

Uploaded by

M Madhavi Asst. Professor, CSE, VRSEC
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Analysis

OOAD UNIT-II
Workflow
CONTENTS
The analysis workflow
 Objects and Classes
 Finding analysis classes
 Relationships
Inheritance and Polymorphism.
ANALYSIS WORKFLOW
The main work in analysis begins toward the end of the Inception
phase and is the main focus of the Elaboration phase, along with
requirements.
Most of the activity in Elaboration is about creating models that
capture the desired behavior of the system
Analysis artifacts - metamodel
In the analysis workflow, two key artifacts are produced:
1. analysis classes - these model key concepts in the business
domain;
2. use case realizations - these illustrate how instances of the
analysis classes can interact to realize system behavior specified
by a use case.
ANALYSIS WORKFLOW
DETAIL
ANALYSIS MODEL - RULES
OF THUMB
1.The analysis model is always in the language of the business. The abstractions found in the
analysis model should form part of the vocabulary of the business domain.
2.Create models that "tell a story". Each diagram produced should elucidate some important
part of the system's desired behavior. If it doesn't, then what purpose does it serve? You'll see
good ways of producing such diagrams when we consider use case realizations.
3.Concentrate on capturing the big picture. Don't get bogged down in the details of how the
system will work-there is plenty of time for this in design.
4.Distinguish clearly between the problem domain (the business requirements) and the
solution domain (detailed design considerations). Always focus on abstractions that exist in
the problem domain.
5. Always try to minimize coupling. Each association between classes creates coupling
between them
6.Explore inheritance if there seems to be a natural and compelling hierarchy of abstractions.
7.In analysis, never apply inheritance just to reuse code. Inheritance is the strongest form of
coupling between classes,
8.Always ask, "Is the model useful to all the stakeholders?" There's nothing worse than
producing an analysis model that is ignored by the business users or the designers and
developers.
OBJECTS AND CLASSES
What are objects?
The UML Reference Manual [Rumbaugh 1] defines an object as "A
discrete entity with a well-defined boundary that encapsulates
state and behavior; an instance of a class.“
it has certain properties that are common to all objects.
Identity
State
Behavior
UML OBJECT NOTATION
The object identifier can consist of any of the following.
1.The class name alone - for example, :Account. This
signifies that you have an anonymous object, or instance
of that class .Anonymous objects are often used when
only one object of a particular class is on a given diagram.
If you need to show two objects of the same class, then
you should give each a name to distinguish them from
each other.

2. The object name alone - for example, jimsAccount. This


identifies a specific object but doesn't identify which class
it belongs to. This notation can be useful in very early
analysis when you haven't yet discovered all the classes.
3. The object name concatenated with the class name,
Object from
separated attribute
eachvalues
other Each object You
by a colon. attribute value
may read has the following form: name : type =
the
value
colon as "is an instance of class".
What are classes?
The UML Reference Manual [Rumbaugh 1] defines a class as "The
descriptor for a set of objects that share the same attributes, operations,
methods, relation ships, and behavior." We could summarize this by
saying that a class is a descriptor for a set of objects that have the same
features.
Classes and objects
The relationship between a class and objects of that class is an
«instantiate» relationship
UML CLASS NOTATION
In analysis models, you typically only
need to show the following: class name;
key attributes;
1.classes
2. key operations;
3.stereotypes (if they have business
significance).
(optional)4. tagged values;
5.operation parameters;
visibility;
initialization values (unless they have
business significance).
Name compartment:
While UML does not mandate any naming convention for classes, there is a
convention that is almost universally followed.
1.Class name is in UpperCamelCase-it begins with an uppercase letter, and
then is in mixed upper- and lowercase, with each word beginning in
uppercase. Special symbols such as punctuation marks, dashes, under scores,
ampersands, hashes, and slashes are always avoided.
2.documentation is generated from the model. Avoid abbreviations at all costs.
3.Class names should always reflect the names of real-world entities without
abbreviation. For example, FlightSegment is always preferable to FltSgmnt,
DepositAccount is always preferable to DpstAccnt.
4. If there are domain-specific acronyms (e.g., CRM - Customer Relation ship
Management) that are in common use and will be understood by all readers of
the model, then you may use them

You might also like