Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 5

1
Software Engineering, CPSC-4360-01,
CPSC-5360-01, Lecture 5  
2
Review of Last Lecture

• Analysis
• Software Architecture.
• Use Case Realization
• Use Case ? Sequence Diagrams.
• Domain Model Refinement
• Domain Model ? Partial Class Diagram.

3
Overview of This Lecture

• Design
• Major activities during design phase.
• Tools
• Class Diagram.
• Object Diagram.

4
Where are we now?

• Flesh out the system design
• Choose the appropriate hardware and software
  environment.
• Detail Class Design.

5
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.

6
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
• Studies interaction using the sequence diagrams.
• Infers information about the classes.

7
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
• Separation between the User Interface and
  Application.
• Relationship between the User Interface and
  Application.

8
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 pre-processed
  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.

9
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.

10
Case Study 1 Presentation Layer

• Packages are included to show the interaction
  between the layers.
• Upon clicking the OK button
• 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.

11
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.

12
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
13
Case Study 1 Inferring Class Information

• User generated events might not have an
  one-to-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.

14
Case Study 1 Text Based User Interface

• Welcome to BR-Booking Reservation System
• Display Booking
• Record Booking
• ... ... ...
• Your Choice -gt 1
• Please Input Date -gt 01/01/2006
• Bookings on 01/01/2006 (Sunday)
• Table 1
• 7pm 9pm YJ (1234) 4 Persons
• 9pm 11pm WH (5678) 6 Persons
• ...
• ...
• ...
• ...

• Although the interface is very different,
  activities are similar
• 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
15
Case Study 1 Text Based User Interface
ltltBoundarygtgt StaffTextUI
ltltControlgtgt BookingSystem
Restaurant
displayOpt ( )
readDate ( )
This part is the same as the Sequence Diagram in
Lecture 4, Slide 37
display( date )
date
getBookings ( date)

bookings
New interactions for the Presentation layer
16
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
• Modifying existing sequence diagrams derived
  during analysis.
• Derive the classes needed
• Messages.
• Class attributes.
• Association with classes in the Application layer.

17
Storage Layer Revisited

• Most systems need persistent data which is
• Not lost when the system closes down.
• Stored in the file system or a database.
• A few possible choices to provide persistency
• Relational databases (RDBMS).
• Object serialization (Java).
• Files input/output.
• Designer needs to
• Identify what data needs to be persistent.
• Identify ways to save/load the data according to
  the storage choice.

18
Designating Persistent Classes

• Case Study 1
• All booking information must be saved.
• But not current date, or selected bookings.

19
Designating Persistent Classes

• In UML, classes are the unit of persistence.
• A persistent class is denoted by a tagged value
  persistent.

20
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?

21
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.

22
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.

23
Simple example (memory view)

AInt 11111
Class A Object
refB 0x00001240

• The reference of class B object is kept as a
  memory address (e.g., 0x00001234) in the object
  of class A.

AInt 22222
Class A Object
refB 0x00001234

Class B Object
BInt 999

Class B Object
BInt 888

24
Simple Example (after saving to file)

• Suppose we save all object attributes directly to
  a text file

• 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.

111110x00001240222220x00001234999888
Text file after saving 4 objects.
25
Simple Example (after reloading)

• 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.

AInt 11111
Class A Object
refB 0x00001240
Class B Object
BInt 888

Class B Object
BInt 999

AInt 22222
Class A Object
refB 0x00001234


26
Simple Example (with oid )

• 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.

AInt 11111
Class A Object
refB 0x00001240
OID 1
B_OID 4




BInt 888
Class B Object
OID 4
27
Simple Example (Save and Reload with oid)

• The identification information oid is saved along
  with other attributes.

• Upon reloading, the objects will be
  re-instantiated with the attributes saved.
• The reference is restored by looking up the
  object that matches oid.

11111148884
Text file after saving 2 objects
28
Simple Example (Restoring Reference)


AInt 11111
AInt 11111
Class A Object
refB ??????
Class A Object
refB 0x001200
OID 1
OID 1
B_OID 4
B_OID 4


BInt 888
BInt 888
Class B Object
Class B Object
OID 4
OID 4




After Restoration
Before Restoration
29
Observations

• A mapping class is needed
• To map oid to actual memory reference.
• To assign oid to objects during new object
  creation.
• Oid behaves just like a key in a database record
• 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.

30
Case Study 1 Adding Persistency Support

• Take the Table class as example
• A subclass is added to incorporate the oid.
• A mapper class is added.

31
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
• Booking
• Customer
• Etc

32
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.

33
Persistency Architecture
34
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.

35
Storage Layer Summary

• Activities during design phase for Storage layer
• 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.

36
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).

37
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
• check redundancy, inconsistency, etc.
• define the operation interface of class.
• specify detailed parameters and return types.

38
Class Diagram Review

• Class is represented by

One Class

• A relationship between classes is represented by
  an association with
• Association name.
• Role name.
• Multiplicity.
• Nagivability (direction).

39
Class Multiplicity

• Multiplicity notation, e.g.
• 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).
• Can be applied to class, known as class
  multiplicity
• Determine the number of instances for a class.
• Default class multiplicity is .
• Special cases can be denoted as

This class can have exactly one instance during
execution.
Class Name
1
40
Attribute Type

• Each attribute should have a type, denoted as
• attribute_name type
• Example

• 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.

41
Enumeration

• Define a new datatype color with the acceptable
  values red, amber, green

• Usage example The traffic light color can be
  either red, amber or green.

The attribute currentLight can only have the
values red, green or amber.
42
Attribute Scope

• Attribute of a class has instance scope by
  default
• i.e., each instance (object) of the class has an
  independent copy of the attribute.
• There are cases where class scope is needed
• 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.
43
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.

44
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.

45
Operation

• Operation uses the following syntax
• Operation_name (parameter type, )
  return_type
• Scope and Accessibility notations are the same as
  the attributes.

• Constructor is denoted as Class Scope operation
  in UML.

46
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.

47
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
• The notation is very similar to a Class Diagram.
• Slight difference in terminology.
• Can help to understand and refine a Class Diagram.

48
Object Diagram First Look

• Object Diagram
• Describes ONE table object,
• with specific values.
• Operations were not included.
• Example Java Code to create this object
• Table tableOne new Table(1,10)

• Class Diagram
• Describes ALL possible Table Objects.

49
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

50
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.

51
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.

Work For gt
John Person
LU Company
Object Diagram
52
Object Diagram Correctness

• An Object Diagram cannot violate constraints laid
  out by the corresponding Class Diagram

Work For gt
John Person
LU Company
Object Diagram
This Diagram is WRONG (why?)
Work For gt
LIT Company
53
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.

54
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

55
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

56
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.

57
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
58
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).

59
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.

60
Inheritance

• The subclass inherits all attributes and
  operations of the superclass.

All Account subclasses have these attributes and
operations.
61
Modifying Subclasses

• Subclasses can
• Add features to model special properties.
• Override operations to implement specialized
  behaviour.

• OnlineAccount
• overrides deposit() and withdraw()

62
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.
63
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 ( )

64
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
65
Cyclic Object Structures

• The Class Diagram on Slide 64 allows the
  following object diagrams

• Not desirable
• Does not reflect the physical world.
• Traversing the hierarchy (e.g., to print out all
  parts and assemblies) causes infinite loops.

66
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
67
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.
68
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 ( ).

69
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?

70
Associations and Composites

• Alternative notation allows associations to be
  defined inside composites.
• The multiplicities associated with composition
  relationships are now class multiplicities.

Class Diagram
Object Diagram
71
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).

72
To Be Continued

• Class Diagram
• Association Class
• N-Ary Association
• Qualified Association
• Continues in next lecture

73
Where are we now?

• Topics Covered
• Detailed Class Diagram
• Object Diagram

74
Summary

• Design
• Major activities during design phase
• Tools
• Class Diagram
• Object Diagram

75
Reading Suggestions

• Chapter 5 of Bimlesh, Andrei, Soo 2007
• Chapters 6 and 8 of Priestley 2004

76
Coming up next

• Chapter 5 of Bimlesh, Andrei, Soo 2007
• Chapter 9 of Priestley 2004

77
Thank you for your attention!Questions?