Transcript Slide 1

Software Engineering,
CPSC-4360-01, CPSC-5360-01,
Lecture 5
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
1
Review of Last Lecture

Analysis:


Software Architecture.
Use Case Realization:


Use Case → Sequence Diagrams.
Domain Model Refinement:

7/16/2015
Domain Model → Partial Class Diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 5
2
Overview of This Lecture

Design:


Major activities during design phase.
Tools:


7/16/2015
Class Diagram.
Object Diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 5
3
Where are we now?
Requirement
Analysis
Design

Flesh out the system
design:

Implement

Choose the appropriate
hardware and software
environment.
Detail Class Design.
Test
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
4
Design: Overview

Inputs:



Software Architecture.
Analysis Class Diagram.
Activities:


Decide and design appropriate classes for other layers
in the Software Architecture.
Refine Analysis Class Diagram:




Produce detailed Class Diagram ready for implementation.
Collaboration Diagrams to study interaction between
classes.
State Chart to study behavior of a class.
Apply Design Pattern.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
5
Design and the Layered Architecture


Analysis shows how business
functions can be implemented in
the application layer.
Design extends this level of
modelling to the other layers, i.e.,
the Presentation and Storage
layers:


7/16/2015
Studies interaction using the
sequence diagrams.
Infers information about the classes.
CPSC-4360-01, CPSC-5360-01, Lecture 5
6
Design: Presentation Layer



Decide the suitable User Interface and design
the classes to support.
Details about designing a good user interface
is not the aim of this course.
Important points independent of the chosen
User Interface:


7/16/2015
Separation between the User Interface and
Application.
Relationship between the User Interface and
Application.
CPSC-4360-01, CPSC-5360-01, Lecture 5
7
Presentation Layer Revisited

System messages have been shown arriving at
the controller in the Application layer:


Questions like “How the user initiates certain events?”,
“How do we get this value from the users?” were
ignored.
In fact, these messages have been ‘preprocessed’ in the Presentation layer:



The boundary object in the Presentation layer models
the system's user interface.
User requests are received and processed before they
are redirected to the controller object.
Responsible for interacting with input devices.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
8
Case Study 1: Graphical User Interface


Assumption: a window-based application, i.e.,
a Graphical User Interface will be used.
Possible sequence of initiating the Display
Booking use case:




Select an appropriate menu option.
Dialogue box appear.
User enters the date and click the OK button.
Should concentrate on the steps that trigger
operations in the Application layer, e.g., the last
step above.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
9
Case Study 1: Presentation Layer


Packages are included to show the interaction
between the layers.
Upon clicking the OK button:


7/16/2015
A message submit( ) is generated which is caught by StaffUI
in the Presentation Layer.
StaffUI sends a display( ) message to the BookingSystem in
the Application Layer.
CPSC-4360-01, CPSC-5360-01, Lecture 5
10
Case Study 1: Mouse Event

Mouse events are handled similarly:


An user interface object translates mouse events into
system messages;
Time and Table are derived from mouse coordinates.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
11
Case Study 1: Inferring Class Information

For GUI, there exists a series of user generated
events for one use case, e.g., Transferring an
existing booking by “Drag and Drop” to a new slot.
Select a
Booking
on screen
Move the
mouse around
“Drop” the
booking to
a new slot
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
12
Case Study 1: Inferring Class Information


User generated events might not have an oneto-one correspondence with System Message.
The boundary objects may need to keep extra
information to:



Remember the state of current interaction.
Deduce when to send a system message.
In the Table Transfer example, the GUI has to:


Remember that Table Transfer is being performed,
even when the user moves the mouse around.
Responsible for sending the transfer() message
when the mouse button is released.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
13
Case Study 1: Text Based User Interface
****************************************
Welcome to BR-Booking Reservation System
****************************************
1.
Display Booking
2.
Record Booking
3.
... ... ...

Although the interface is
very different, activities
are similar:
Your Choice -> 1

Please Input Date -> 01/01/2006

Bookings on 01/01/2006 (Sunday):
Table 1:
7pm – 9pm: YJ (1234): 4 Persons
9pm – 11pm: WH (5678): 6 Persons
...
...
...
...


Design UI.
Study Interaction.
Design the UI classes.
Text Based UIs are
slightly easier to design
as the order of events is
well defined.
Restaurant Booking System – Text Based UI
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
14
Case Study 1: Text Based User Interface
<<Boundary>>
:StaffTextUI
:Staff
<<Control>>
:BookingSystem
:Restaurant
displayOpt ( )
readDate ( )
display( date )
date
getBookings ( date)
……
This part is the
same as the
Sequence
Diagram in
Lecture 4, Slide 37
bookings
New interactions for
the Presentation layer
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
15
Presentation Layer: Summary

Activities during design phase for Presentation layer:



Decide the appropriate type of User Interface.
Draft the User Interface.
Study the interaction to perform each of the use cases:


Derive the classes needed:



7/16/2015
Modifying existing sequence diagrams derived during analysis.
Messages.
Class attributes.
Association with classes in the Application layer.
CPSC-4360-01, CPSC-5360-01, Lecture 5
16
Storage Layer: Revisited

Most systems need persistent data which is:



A few possible choices to provide persistency:




Not lost when the system closes down.
Stored in the file system or a database.
Relational databases (RDBMS).
Object serialization (Java).
Files input/output.
Designer needs to:


7/16/2015
Identify what data needs to be persistent.
Identify ways to save/load the data according to the storage
choice.
CPSC-4360-01, CPSC-5360-01, Lecture 5
17
Designating Persistent Classes

Case Study 1:


All booking
information
must be saved.
But not current
date, or
selected
bookings.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
18
Designating Persistent Classes

In UML, classes are the unit of persistence.

7/16/2015
A persistent class is denoted by a tagged value
{persistent}.
CPSC-4360-01, CPSC-5360-01, Lecture 5
19
Saving and Reloading Object

As an object exists only during the program
execution, there is no clear counterpart in the
static storage, i.e., you cannot save an “object”
directly to a file.



Instead, attributes of an object are saved.
Upon reloading, the attributes are read and an
object is recreated using the same attributes,
giving the illusion that “object” is loaded from a
static storage.
This works well for objects that contain only
simple values, but what about reference?
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
20
Preserving Association

An association between objects operates
using reference (memory address):



The memory address of an object may be
different upon reloading as the object is
reallocated.
An identification information to locate an object is
needed to restore the association.
A simple way is to assign an unique id to
each object.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
21
Simple Example


Example to highlight the problem of saving/loading
objects.
Given the code fragment below:
class A {
int AInt;
B refB;
...
}


class B {
int BInt;
...
}
Assume we instantiated two objects of class A and
link them to two objects of class B.
A memory view during execution is on next page.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
22
Simple example (memory view)
……
Class A
Object
AInt:
11111
refB: 0x00001240
……
Class A
Object
AInt:
22222
refB: 0x00001234

The reference of class B
object is kept as a memory
address (e.g., 0x00001234)
in the object of class A.
……
Class B
Object
BInt:
999
……
Class B
Object
BInt:
888
……
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
23
Simple Example (after saving to file)

Suppose we save all object attributes directly
to a text file:

11111
0x00001240
22222
0x00001234
999
888


Text file after saving 4 objects.
7/16/2015
Upon reloading, the attributes for
each object are read (e.g., the
first two lines for class A object).
And a new object of the desired
class is instantiated with the
information read.
As we have no way to influence
where to place an object, the
object reference no longer
works….
CPSC-4360-01, CPSC-5360-01, Lecture 5
24
Simple Example (after reloading)
……
Class A
Object
AInt:

11111
refB: 0x00001240
Class B
Object
BInt:
Class B
Object
BInt:
888

……
999
……
Class A
Object
AInt:
22222
refB: 0x00001234

Let us add an oid to each
object.
Instead of remembering
the reference, the oid is
kept instead.
Note: Only one pair of objects
A and B is shown on next page
to simplify the diagram.
……
……
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
25
Simple Example (with oid )
……
Class A
Object
AInt:
11111

refB: 0x00001240
OID:
1
B_OID:
4
……
……

……
……
Class B
Object
7/16/2015
BInt:
888
OID:
4
The object of class A
contains its own oid,
as well as the oid for
the class B object that
it reference (B_oid).
Memory reference is
used during runtime
to allow quick access.
CPSC-4360-01, CPSC-5360-01, Lecture 5
26
Simple Example (Save and Reload with
oid)

The identification information oid is saved
along with other attributes.

11111
1
4
888
4

Text file after saving 2 objects
7/16/2015
Upon reloading, the objects
will be re-instantiated with the
attributes saved.
The reference is restored by
looking up the object that
matches oid.
CPSC-4360-01, CPSC-5360-01, Lecture 5
27
Simple Example (Restoring Reference)
……
Class A
Object
……
AInt:
11111
refB:
??????
OID:
1
B_OID:
4
Class A
Object
AInt:
11111
refB:
0x001200
OID:
1
B_OID:
4
……
Class B
Object
7/16/2015
……
BInt:
888
OID:
4
Class B
Object
BInt:
888
OID:
4
……
……
……
……
Before Restoration
After Restoration
CPSC-4360-01, CPSC-5360-01, Lecture 5
28
Observations

A mapping class is needed:



Oid behaves just like a key in a database record:




To map oid to actual memory reference.
To assign oid to objects during new object creation.
The whole process is equally applicable when using DBMS
instead of an I/O file.
Using an oid to identify other objects is equivalent to using a
foreign key to identify other record.
DBMS is beyond the scope of this course.
However, the process/steps are still valuable insights.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
29
Case Study 1: Adding Persistency Support

Take the Table class as example:


7/16/2015
A subclass is added to incorporate the oid.
A mapper class is added.
CPSC-4360-01, CPSC-5360-01, Lecture 5
30
Case Study 1: Adding Persistency Support




The PersistentTable subclass is added so that other
classes that depend on the Table class will not be
affected.
Incorporating oid directly into the Table class would
limit the possible choice of persistency support.
The TableMapper class is responsible for creating
objects of the PersistentTable class and restoring them
from persistent storage if required.
Apply the same idea to other classes that require
persistency support:



7/16/2015
Booking
Customer
Etc…
CPSC-4360-01, CPSC-5360-01, Lecture 5
31
Case Study 1: Persistency Architecture



Persistent subclasses and mapper classes depend on the
class they are supporting.
 So, they must be in the Application layer.
The Restaurant class is dependent on mapper classes:
 Restaurant uses the mapper class to create an object with
persistency support.
In order to preserve layered architecture:
 Split the Application layer into two sub-packages:



Domain sub-package for all classes directly related to problem domain.
Persistency sub-package for persistency support classes has minimal
effect on the ‘Domain’ sub-package.
Changing the Persistency sub-package should have a
minimum impact on the Domain sub-package.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
32
Persistency Architecture
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
33
Persistency Sub-Package: Possible
Questions


One possible way of achieving persistency has been
described.
There are other possible questions:

When to save/load objects?






Load on execution starts, Save on exit?
Save on creation/modification?
Load only when needed?
Should the system provide backup?
Should the system be crash-proof?
These constraints should be taken into account when
designing the persistency support.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
34
Storage Layer: Summary

Activities during design phase for Storage
layer:




7/16/2015
Identify classes that require persistency support.
Choose appropriate persistency service.
Introduce classes to work with the chosen
persistency service.
Additional sequence diagram can be drawn to
capture the operations needed.
CPSC-4360-01, CPSC-5360-01, Lecture 5
35
Design Phase: The rest of the journey


At this point, the basic technique/activity
during design phase is covered.
Subsequent lectures (up to lecture 8)
will take a closer look at the tools
(relevant UML diagrams) and one
important technique to enhance the
design (design patterns).
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
36
Detailed Class Design

Create a detailed class specification that
could be used as a basis for implementation.


Start with analysis class model.
Collect messages from all realizations:



7/16/2015
check redundancy, inconsistency, etc.
define the operation interface of class.
specify detailed parameters and return types.
CPSC-4360-01, CPSC-5360-01, Lecture 5
37
Class Diagram: Review

Class is represented by:
Class Name
Attributes
One Class
Operations

A relationship between classes is represented by an
association with:




7/16/2015
Association name.
Role name.
Multiplicity.
Nagivability (direction).
CPSC-4360-01, CPSC-5360-01, Lecture 5
38
Class Multiplicity

Multiplicity notation, e.g.:





Can be applied to class, known as class multiplicity:



3 (three only, specific number).
2..8 (two to eight only, specific range).
1,3,5 (either one, three or five only).
* (zero to many).
Determine the number of instances for a class.
Default class multiplicity is *.
Special cases can be denoted as:
1
Class Name
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
This class can have
exactly one instance
during execution.
39
Attribute Type

Each attribute should have a type, denoted as:
attribute_name: type

Example:
Table
number: Integer
places: Integer



UML defines only Integer, String, Boolean.
Specific Programming Language types are usually
allowed, e.g., Float, Double, Char, etc.
UML allows definition of a new type using enumeration.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
40
Enumeration

Define a new datatype color with the acceptable
values red, amber, green:
<<enumeration>>
Color
red
amber
green

Usage example: The traffic light color can be either
red, amber or green.
TrafficLight
currentLight: Color
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
The attribute
currentLight can only
have the values red,
green or amber.
41
Attribute Scope

Attribute of a class has instance scope by default:


There are cases where class scope is needed:


i.e., each instance (object) of the class has an independent
copy of the attribute.
All instances share one copy of the attribute (also known
as class attribute in Java).
Denote by underlining the attribute:
There is only one
copy of totalTable
regardless of the
number of Table
objects.
7/16/2015
Table
number: Integer
places: Integer
totalTable: Integer
CPSC-4360-01, CPSC-5360-01, Lecture 5
42
Attribute Visibility


Equivalent to the accessibility level in languages like
C++, Java.
UML defines four levels of accessibility:




public (+): visible to all classes.
protected (#): visible to instances of subclasses.
private (-): visible only in the same class.
package (~): visible to classes in the same package.
• number and places are private
to each object.
• totalTable is accessible to
everyone.
7/16/2015
Table
- number: Integer
- places: Integer
+ totalTable: Integer
CPSC-4360-01, CPSC-5360-01, Lecture 5
43
Attribute Multiplicity

Attribute multiplicity defines how many values
an object stores for an attribute:



default is exactly 1.
optional multiplicity shows possible null values.
arrays modelled by * (many) multiplicity.
Module
- examDate [0..1]: Date
- staff [*]: String
... ...
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
44
Operation

Operation uses the following syntax:
Operation_name (parameter: type, …) : return_type

Scope and Accessibility notations are the same as the
attribute’s.
Table
- number: Integer
- places: Integer
+ totalTable: Integer
+
+
+
+

getNumber( ): Integer
setNumber(n: Integer)
getTotal( ): Integer
Table(n: Integer, p: Integer)
Constructor is denoted as Class Scope operation in UML.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
45
Constructing Class Diagram


Study relevant structures (usually real world
entities) and generalize to class diagram.
May be difficult in complicated cases:



We need a way to study specific examples instead
of all possible scenarios.
From a few representative examples, we generalize
to a structure that is able to support all cases.
An object diagram is introduced to study
specific examples instead of general cases.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
46
Object Diagram

Classes in a program describe all possible instances
(objects).


During program execution, only a subset of all possible
objects are instantiated.
Similarly, UML defines Object Diagrams to examine
instances (possible scenarios) of Class Diagrams:



7/16/2015
The notation is very similar to a Class Diagram.
Slight difference in terminology.
Can help to understand and refine a Class Diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 5
47
Object Diagram: First Look
Table
tableOne: Table
- number: Integer
- places: Integer
number = 1
places = 10
+ getNumber( ): Integer
+ setNumber(n: Integer)



Class Diagram:

Object Diagram:
Describes ALL possible
Table Objects.


Describes ONE table object,
with specific values.
Operations were not included.
Example Java Code to create
this object:
Table tableOne = new Table(1,10);
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
48
Object Diagram: Closer Look

An object is given an object name:




Represents the identity of an object.
So that it can be easily referred in the diagram.
Usually it corresponds to the variable name in
programming construct for convenient sake:
 An object variable in Java is a reference.
 Multiple object variable can refer to the same object.
 However, one object can have only one object name
in UML.
Denoted by:
objectName: ClassName
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
49
Object Diagram: Closer Look

The object name can be omitted when we are not
interested in knowing the exact object in action:
:Person


The attributes of an object have specific values.
Denoted by:
attributeName = value

Operations of an object are not shown as all objects
of the same class have the same set of operations.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
50
Object Diagram: Link



An association in a Class Diagram describes a general
relationship between classes.
An instance of association (link) connects two specific
objects in an Object Diagram.
Association Names are underlined in an Object Diagram
to represent a link.
Class
Diagram:
Object
Diagram:
7/16/2015
Person
Work For >
Company
Work For >
John: Person
LU: Company
CPSC-4360-01, CPSC-5360-01, Lecture 5
51
Object Diagram: Correctness

An Object Diagram cannot violate constraints laid
out by the corresponding Class Diagram:
Class
Diagram:
Object
Diagram:
Person
Work For >
*
1
Company
Work For >
John :Person
LU: Company
Work For >
This Diagram
is WRONG
(why?)
LIT: Company
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
52
Object Diagram: Usefulness

Use an Object Diagram to sketch real world
scenarios:



Can check whether the Class Diagram can
correctly support possible cases.
E.g., if a person is allowed to take two jobs as in
the last object diagram, then the class diagram
needs to be modified.
Can be used to visualize the execution of a
code fragment.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
53
Class Generalization



Commonality between classes (shared attributes and
operations) can be extracted (generalized) into a
superclass.
Using bank accounts as an example, there are three
types of accounts: CurrentAccount, DepositAccount,
and OnlineAccount.
Introduce a superclass Account to capture the similarity:
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
54
Meaning of Generalization

Within UML, generalization means substitutability:


In any context where an instance of a superclass is expected, an
instance of a subclass can be substituted for it without any
problems.
Example: A customer can holds many accounts of
different types:
Class Diagram
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
55
The Meaning of Generalization (cont)



E.g., in any context where an instance of a superclass
is expected, an instance of a subclass can be
substituted for it without any problems.
The association of figure from previous slide implies
that instances of Customer and Account classes can
be linked at run-time.
Because of substitutability, an Account instance can
be replaced by an instance of any of the subclasses of
Account.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
56
Substitutability

This model connects Customers to Accounts.
but an instance of any subclass can be substituted for
an account object.
 these links demonstrate polymorphism.
Example: the links between Customer and different
Accounts objects represent instances of the
association between Customer and account classes.


Object Diagram
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
57
Abstract Class

Superclasses are often defined solely to group
together shared features:



May not make sense to have an instance of a superclass.
In this case, define the class as abstract.
In UML, abstract classes are written in an italic
typeface (e.g., Account).
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
58
Generalization Hierarchies


The generalization process can be carried out at
different level if needed.
A hierarchy can be developed to as many levels as
required.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
59
Inheritance

The subclass inherits all attributes and operations of
the superclass.
All Account subclasses
have these attributes
and operations.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
60
Modifying Subclasses

Subclasses can:


Add features to model special properties.
Override operations to implement specialized behaviour.
OnlineAccount:
overrides deposit() and
withdraw()
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
61
Abstract Operations

Some operations cannot be implemented in abstract
classes.


Solution: define them as abstract and override them in
subclasses.
Use italic typeface for the operation name.
Not meaningful
to implement in
Shape class.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
62
Association: Aggregation


Aggregation is a sub-case of association:
 Informal Model: the ‘whole-part’ relationships.
 An object is ‘part of ’ another object.
 Standard association annotation still applicable.
Denoted by a hollow diamond (
)
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
63
Cyclic Object Structures


Aggregation is useful for ruling out invalid cyclic object
structures.
Example: An Assembly can contain any number of
Parts and other Assemblies.
Class Diagram
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
64
Cyclic Object Structures

The Class Diagram on Slide 64 allows the following
object diagrams:

Not desirable:


7/16/2015
Does not reflect the physical world.
Traversing the hierarchy (e.g., to print out all parts and
assemblies) causes infinite loops.
CPSC-4360-01, CPSC-5360-01, Lecture 5
65
Property of Aggregation

Aggregation forbids cycling structure because it is:


Anti-symmetric: an object cannot link to itself.
Transitive: if a links to b and b to c, then a links to c.
Change to
Aggregation
Class Diagram
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
66
Cyclic Object Structures

The two object structures in the object diagram on
slide 63 are now invalid. (why?)
Invalid because:
Invalid because:
Note: Intentionally left incomplete. Try before the lecture.
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
67
Association: Composition

Composition is a strong form of aggregation:



Parts can only belong to one composite at a time.
Parts are destroyed (deleted) when a composite is
destroyed.
Denoted by a filled diamond (
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
).
68
Component Relationship

Model the fact that:



Processor must belong to a computer.
Port must also belong to a computer.
Question: Is the fact “Processor must be connected
to the Port on the SAME computer” modeled?
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
69
Associations and Composites


Alternative notation allows associations to be defined
inside composites.
The multiplicities associated with composition
relationships are now class multiplicities.
Class Diagram
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
Object Diagram
70
Composite Boundary


Associations can cross the boundary to link objects in
different composites.
Example: network modelling (ports linked by the instances
of the association can belong to different composite
objects).
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
71
To Be Continued…

Class Diagram:




Association Class
N-Ary Association
Qualified Association
Continues in next lecture
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
72
Where are we now?
Requirement
Analysis

Topics Covered:

Design

Detailed Class Diagram
Object Diagram
Implement
Test
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
73
Summary

Design


Major activities during design phase
Tools:


7/16/2015
Class Diagram
Object Diagram
CPSC-4360-01, CPSC-5360-01, Lecture 5
74
Reading Suggestions


Chapter 5 of [Bimlesh, Andrei, Soo; 2007]
Chapters 6 and 8 of [Priestley; 2004]
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
75
Coming up next


Chapter 5 of [Bimlesh, Andrei, Soo; 2007]
Chapter 9 of [Priestley; 2004]
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
76
Thank you for your attention!
Questions?
7/16/2015
CPSC-4360-01, CPSC-5360-01, Lecture 5
77