uml

2. Introduction to UML:
• Importance of modeling
• Principles of modeling
• Object oriented modeling
• conceptual model of the UML
• Architecture
• Software development life cycle; Classes, relationships, common
mechanisms and diagrams.

3. Object oriented modeling
• It is a new way of thinking about problems.
• visualizing the things by using models organized around real world
concepts.
• It is a encouraging approach in which software developers have to
think in terms of the application domain through most of the
software engineering life cycle.
• In this process, the developer is forced to identify the inherent
concepts of the application.
• First, developer organize, and understood the system properly and
then finally the details of data structure and functions are addressed
effectively.

4. In OOM the modeling passes through the following processes:
• System Analysis
• System Design
• Object Design
• Final Implementation.

5. • System analysis:
how the desired system must be developed.
• System Design:
At this stage, the complete system architecture is designed.
• Object Design:
The object design decides the data structures and algorithms needed to
implement each of the classes in the system with the help of implementation
details given in the analysis model.

6. CHARACTERISTICS OF OBJECT ORIENTED MODELING
• Class and Objects
• Links and Association
• Generalization and Inheritance

7. Classes
• a class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
• Each of these things, or concepts is called an object.
• A class implements one or more interfaces.
• A class is a rectangle divided into three parts
• Class name
• Class attributes (i.e. data members, variables)
• Class operations (i.e. methods)

8. • Modifiers
• Private: -
• Public: +
• Protected: #
• Static: Underlined (i.e. shared among all members of the class)
• Abstract class: Name in italics
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
Employee

9. • Lines or arrows between classes indicate relationships
• Association
• A relationship between instances of two classes, where one class must know about the other to
do its work, e.g. client communicates to server
• indicated by a straight line or arrow
• Aggregation
• An association where one class belongs to a collection, e.g. instructor part of Faculty
• Indicated by an empty diamond on the side of the collection
• Composition
• Strong form of Aggregation
• Lifetime control; components cannot exist without the aggregate
• Indicated by a solid diamond on the side of the collection
• Inheritance
• An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal
• Indicated by triangle pointing to superclass

10. Binary Association
myB.service(); myA.doSomething();
Binary Association: Both entities “Know About” each other
Optionally, may create an Associate Class

11. Unary Association
A knows about B, but B knows nothing about A
Arrow points in direction
of the dependency
myB.service();

12. Aggregation
Aggregation is an association with a “collection-member” relationship
void doSomething()
aModule.service();
Hollow diamond on
the Collection side
No sole ownership implied

13. Composition
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
-adfaf : bool
Employee
-members : Employee
Team
1
*
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Filled diamond on
side of the Collection
members[0] =
new Employee();
…
delete members[0];

14. Inheritance
Standard concept of inheritance
class B() extends A
…
Base Class
Derived Class

15. UML Multiplicities
Multiplicities Meaning
0..1
zero or one instance. The notation n . . m
indicates n to m instances.
0..* or *
no limit on the number of instances
(including none).
1 exactly one instance
1..* at least one instance
Links on associations to specify more details about the relationship

16. UML Class Example

17. Association Details
• Can assign names to the ends of the association to give further
information
+getName
() : string
+setName
()
-calcInternalStuff
(in x : byte, in y : decimal
)
-Name: string
+ID : long
#Salary: double
-adfaf: bool
Employee
-members: Employee
Team -group
1
-individual
*

18. Static vs. Dynamic Design
• Static design describes code structure and object relations
• Class relations
• Objects at design time
• Doesn’t change
• Dynamic design shows communication between objects
• Similarity to class relations
• Can follow sequences of events
• May change depending upon execution scenario
• Called Object Diagrams