SWT - Diagrammatics Lecture 3/4 - Diagramming in OO Software Development - partA 2-May-2000.
-
Upload
scot-simon -
Category
Documents
-
view
217 -
download
1
Transcript of SWT - Diagrammatics Lecture 3/4 - Diagramming in OO Software Development - partA 2-May-2000.
SWT - Diagrammatics
Lecture 3/4 - Diagramming in OO Software Development - partA2-May-2000
Previous Lecture Review
• Diagram Distinctions :– Adjoinment, Linkage, Containment.
• Diagram Taxonomies.• Diagram use in Computer Science :
– Venn, Flowcharts, NSD’s, Structure, Dataflow, ERD’s, Cell and Arrows, State, Petri nets.
• Logic Gate Diagrams.• How to operate Theseus under CM.
Overview– OO Introduction,– OO Design Notations, – Objects, Messages / Control & Data Flow, Classes.– Class Attributes and Operations,– Visibility of Attributes and Operations,– Relationships :
– Association, Multiplicity, Aggregation,– Dependency, Inheritance.
– Object Oriented Views
• OO Systems are viewed as compositions of domain specific object abstractions, rather than data and functions. Objects associate data and behaviour.
• Objects in a System inter-communicate by sending messages to each other.
• An Object is a domain concept that has :– State– Behaviour– Identity
What OO Systems are?
OO Software Engineeringhas three distinctive OO processes :
• OO Analysis (OOA) focuses on the understanding of real-world models.
• OO Design (OOD) stresses the mapping of the OOA model to structured architectures, and
• OO Programming (OOP) deals with the building of OOD models under the constraints of the existing environments.
The Object Model
Is a view of the world in terms of Objects and their relationships.
Object Oriented Design Notations• OOD is one of CS’s disciplines that make heavy use of
diagrams.• There are many different OOD notations, all conveying the
same (more or less) information about the systems they describe :
• Coad/Yourdon, Fusion, Jacobson, Martin/Odell, Shlaer and Mellor, Wirfs-Brock et al, Meyer etc
• Three are the most popular ones :– Booch,OMT, UML.
• You can use which ever you prefer, however UML became the standard in OO design on feb’97.
Objects• An object is an atomic entity, formed from the union of state
and behaviour.• Provides encapsulation.• Provides a weak coupling with the outside world.• Software objects define an abstract representation of real
or virtual world entities.
Visible behaviour
Hidden internal state
An object
Objects• In Booch, objects are represented by clouds.• In OMT as in UML, objects are represented by rectangles.• In UML, the name of the object is underlined.
Name : Class Name : Class Name : Class
Booch OMT UML
Messages / Control & Data Flow• The message is the unit of inter-object communication.• It allows interaction in a flexible manner.• It is responsible for the delegation of tasks, and guarantees
that constraints are satisfied.• A message combines control flows and data flows within a
single entity.• The notion of a message is an abstract concept: it could be a
constructor, a method call, a discrete event, an interrupt, a UDP datagram etc.
Object1 Object2Message A Control FlowData Flow
Data Flow
Messages / Control & Data Flow• In the three notations, messages are represented using arrows near the links.• The control flow type is represented by using a line decorated with an
arrowhead.• A small circle connected to the line indicates a data flow, with the arrow
pointing to the direction of the flow.• This notation is optional and has become redundant.
Booch OMT UML
Data flowrepresentedby the messagelabels
Classes
A Class
• A class is the product of an abstraction process which starts with the identification of common characteristics of a set of elements, and proceeds to the concise description of these characteristics.
• The abstraction process is arbitrary: it is defined with respect to a particular viewpoint
Classes• A class describes the definition domain of a set of objects.• It acts as a “mould” from which objects can be created.• Software objects are built from the class, via a process called “instantiation”, objects are
“instances” of classes.• In Booch, classes are represented using dotted clouds.• In OMT, as in UML, classes are represented using rectangles.
Class Class
Booch OMT UML
Class Attributes and Operations
• Each class is represented as a rectangle subdivided into three components :– The name of the class,– The attributes of the class,– The operations of the class,
• By default, attributes are hidden and operations are visible.• These compartments may be omitted to simplify the diagrams.
Class name
Operations( )
Attributes
Class Attributes and Operations• In all three notations, attributes and operations are represented
within the class glyph.• Some attributes can be hidden for the sake of readability.• OMT and UML use boxes to distinguish the attributes from the
operations.
Class name
Operations( )
Attributes
Class name
Operations( )
Attributes
Booch OMT UML
Class name Attributes Operations( )
Visibility of Attributes and Operations• Visibility rules complement and refine the concept of
encapsulation.• It is possible to customise the degree of protection to the
benefit of a class client by declaring attributes as public, protected or private.
• One of the benefits of breaking encapsulation can be, for example, to reduce the time required to access attributes by making unnecessary to call setters/getters. Could this be a right decision? Class name
+ Public Operation( )# Protected Operation( )- Private Operation( )
+ Public Attribute# Protected Attribute- Private Attribute
Visibility of Attributes and Operations• The three notations encompass public, protected and private
levels of protection.• Booch provides an additional “implementation” level.
Class name
+ Public Operation( )# Protected Operation( )- Private Operation( )
+ Public Attribute# Protected Attribute- Private Attribute
Booch OMT UML
Class name
+ Public Operation( )# Protected Operation( )- Private Operation( )
+ Public Attribute# Protected Attribute- Private Attribute
Class name Public Attribute| Protected Attribute| | Private Attribute Public Operation( )| Protected Operation( )| | | Private Operation( )
Nothing public| protected| | private| | | implementation
Nothing unspecified+ public# protected- private
+ public# protected- private
Relationships: Association• The association relationship expresses a bi-directional,
semantic connection between classes.• An association is an abstraction of the links that exist between
object instances.• It is possible to specify the role of a class within an association.• A role name may be specified on either side of the association.
University StudentDean
Relationships: Association
• In all the three notations, an association is represented by a continuous line between the classes that participate in it.
StudentUniversity
Booch OMT & UML
University Student
Multiplicity• Relationships between classes carry multiplicity information that
specifies the number of instances that participate in the relationship• The table below summarises the most common multiplicity values :
Symbol Meaning1 One and only one0..1 Zero or oneM..N From M to N (natural integers)* From zero to any positive integer0..* From zero to any positive integer1..* From one to any positive integer
University Student1 0..* 1 1
Dean
Multiplicity
• OMT proposes a graphical representation based on circles.• Take care not to confuse these circles with those meaning has
and uses in Booch, as there is no relationship between these two representations.
Booch OMT UML
10..1N3..5, 7, 153..N
10..1*3..5, 7, 153..*
0..1
0..N
3..5
1+
1 by default
Relationships: Aggregation• An aggregation is a particular kind of association that
expresses a stronger coupling between classes.• Aggregation allows the representation of relationships like
“master and slave”, “all and part of” and “composed of and components”.
• It is commonly referred to as a “HasA” (or “HasMany”) relationship.
Car Engine1
1
Relationships: Aggregation• There is no strict equivalence between the Booch, OMT and UML
notations.• As aggregation is concerned, Booch is closer to the design phase,
OMT is closer to the analysis stage, and UML covers both.• 2 cases are illustrated for each design methodology : aggregation
by reference and aggregation by value (same in OMT)
Car Engine
Booch OMT UML
Car EngineCar Engine
Car Engine Car Engine Car Engine
Relationships: Dependency• A dependency is a “loose” association that expresses a weaker
coupling between classes.• Usually dependency shows that a class uses another class
with one way or another, maybe by using the other class’s static methods or by passing objects of the second class’s type to another object of another class.
• It is commonly referred to as a “Uses” relationship.
AssemblerRobot
Car Parts1
1..*
Relationships: Dependency• Booch represents a dependency using an association labelled
with a small circle placed on the client side.• OMT represents a dependency using a dotted arrow with a
filled head.• UML uses a dotted arrow with an open head.• In OMT and UML the arrow points to the supplier – the element
being dependent on.
Robot PartsRobot PartsRobot Parts
Booch OMT UML
Relationships: Inheritance• Inheritance is a technique offered by programming languages to construct
a class from one or more (in C++) classes, sharing attributes, operations and sometimes constraints within a hierarchy of classes.
• A class can specialise, extend, subclass, or be a child of another class.
Shape
Star
is a
Vehicle
Car Bike
Audi BMW Yamaha Suzuki
Relationships: Inheritance• Inheritance propagates the characteristics of the parent class (depending
on their visibility) into the child classes.• It is commonly read as an “IsA” relationship.
Relationships: Inheritance• In all three notations, inheritance is represented using an arrow
that points from the subclass to the superclass.
Vehicle
Car
Bike
Vehicle
Car
Vehicle
Car Bike
Vehicle
CarOr as in OMT
Vehicle
Vehicle
Car
Car Bike
Booch OMT UML
Object Oriented views
• Hierarchy view (usually static) :– classes, interfaces and their relationships.
• Interaction view (usually dynamic) :– objects, method calls, events, messages.
• Modules view :– name spaces, packages-libraries-modules,
classes, and their internal and external dependencies.
Hierarchy View
• Inheritance, • Aggregation,• Uses.
Shape
Rect
draw()toString()setText()
draw()setOrigin()setColor()
Oval
draw()toString()setText()
Line
draw()toString()setText()
Drawable
draw()
TestProgram
main()
is
hasimplements
Relationships :
Interaction View
• Is based on objects and method calls.• Depicts the runtime of the system.
myTestprogram
drawAll()
myVector
elements()
myEnum
*[hasMoreElements()]nextElement()
myShape
draw()
Module View
framework
tools
figures
util
commands
guidomain
• Package Visibility• Package Dependencies
The end of lecture 3