8/7/2015CPSC-4360-01, CPSC-5360-01, Lecture 41 Software Engineering, CPSC-4360-01, CPSC-5360-01,...
-
Upload
denis-lucas -
Category
Documents
-
view
221 -
download
0
Transcript of 8/7/2015CPSC-4360-01, CPSC-5360-01, Lecture 41 Software Engineering, CPSC-4360-01, CPSC-5360-01,...
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 1
Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 4
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 2
Review of Last Lecture
Introduction to Case Studies Requirement Gathering Use Case Modeling Domain Modeling / Business Modeling Activity Diagram
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 3
Overview of This Lecture
Analysis Software Architecture Use Case Realization
Use Case → Sequence Diagrams Domain Model Refinement
Domain Model → Partial Class Diagram
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 4
Where are we now?
Requirement
Analysis
Design
Implement
Test
Analyze the system requirements.
Use Case Realization: Understanding how
business entities can be used to support use cases.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 5
Analysis: Overview
Inputs: Use Cases. Domain Model.
Activities: Draft Software Architecture. Realize Use Cases into Sequence Diagrams. Refine Domain Model into Analysis Class
Diagram.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 6
Analysis: Overview The first bridging step from the external view (system
behavior) to the internal view (system implementation). Requirements (Use Cases) give the external view. The Domain Model gives structural information about
business entities. The Analysis is performed to understand how the
business entities can be implemented and support use cases via Use Case Realization: Adding operations to the business entities; Move closer to an actual class in program.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 7
Difference between Analysis & Design Distinction is not clear between the two activities:
Usually seen as one continuous activity with no clear boundary;
Made worse by using the same UML diagrams. Analysis:
Describes the structure of a real-world application; Focus on requirements of system.
Design: Describes the structure of a proposed software
system; Focus on software structure that implements the
system.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 8
Difference between Analysis & Design While analysis model refers to identifying relevant
objects in the real-world system, the design model is adding specific implementation details to the underlying analysis model.
Famous phrase (page 7, [Larman, 2005]): “do the right thing (analysis), and do the thing right (design).”
Example: Flight Information System [Larman, 2005] Analysis: finding and describing the concepts/objects: Plane,
Flight, Pilot, … Design: defining software objects and how they collaborate to
fulfill the requirements: a Plane object may have a tailNumber attribute and a getFlightHistory() method, …
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 9
What is Software Architecture? High level description of the overall system:
The top-level structure of subsystems. The role and interaction of these subsystems.
Grouping of classes to: Improve Cohesion. Reduce Coupling.
Cohesion: Set of “things” that work well together.
Coupling: Inter-Dependency between two entities.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 10
Software Architecture: Example Take the minesweeper game as an example, and
identify the high level components:
Display: Showing the game graphically.
Application Logic: Determining the flags, numbers. Checking whether there are more
mines, etc. Record Storage:
Storing high scores, setting, etc.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 11
Minesweeper: System Oneclass Minesweeper{
public void ClickOnSquare( ){if (square == bomb) {
gameState = dead show dead icon write high score to file}else if (square == number){ open neighboring squares mark squares as opened display new board
}}………..// some other code}
Bad Cohesion: Display functions all
over the place. Application logic buried
under other operations. Storage function not
clearly separated. Low Coupling:
Since there is only one class, there is no inter-dependency!
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 12
Minesweeper: System Twoclass MSGUI {
Minesweeper msApp; MSStorage msStore;
public void mouseClickOnSquare( ){ msApp.openSquare(..); board = msApp.getCurrentBoard(..); show(board); } public void menuExitClick( ) { score = msApp.getHighScore( ); msStore.writeHighScore(score); }}
class Minesweeper {
MSStorage msStore;
public void openSquare(position){if (square == bomb)
gameState = dead;else if (square == number){ open neighboring squares mark squares as opened;}
}
public Board getCurrentBoard() { ..
}
public void saveCurrentBoard() { msStore.writeBoard(..); }}
class MSStorage {
public void writeHighScore(..){ } public void writeBoard(..) { }}
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 13
Minesweeper: System Two Cohesion:
Each class groups logically similar functionality together: Class MSGUI: user interface, input/output to screen; Class Minesweeper: computation and logic; Class MSStorage: file operations.
Coupling: Some interdependencies. Can be improved. Observe that MSGUI uses MSStorage directly. Hence, if we substitute another user interface, the high
score saving functionality needs to be recorded.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 14
Minesweeper: System Three
class MSGUI {
Minesweeper msApp; // MSStorage msStore; Not needed
.. .. ..
public void menuExitClick( ) {msApp.closingDown( );
}}
class Minesweeper {
MSStorage msStore;
.. .. ..
public void closingDown() { msStore.writeHighScore(..) }
public void saveCurrentBoard() { }}
class MSStorage {
public void writeHighScore(..){ } public void writeBoard(..){ }}
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 15
Minesweeper: System Three
Coupling: Reduced. MSGUI depends on Minesweeper only. Minesweeper depends on MSStorage only.
Low coupling enables easy maintenance, e.g.: Changing MSGUI to MSTextUI would not affect the
main application at all. Can swap in another storage class, e.g., database
storage, by providing the same methods.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 16
Minesweeper: Systems Comparison
System 2
Minesweeper
System 3
MSGui
MSStorage
Minesweeper
MSGui
MSStorage
System 1
Minesweeper
Bad Cohesion
No Coupling
Good Cohesion
Medium Coupling
Good Cohesion
Low Coupling
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 17
Minesweeper: Observations
Trade off between cohesion and coupling: Improving cohesion usually implies worse (higher) coupling
and vice versa. The three categories of functionality are quite widely
applicable: User Interface. Main Application Logic. Storage (Persistency).
These observations help shaping Software Architecture: splitting a system into sub-systems.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 18
The Layered Architecture One of the oldest idea in Software Engineering. Split into three separate layers:
Presentation Layer User Interface.
Application Layer The underlying logic. Implements the functionality of system.
Storage Layer Deals with data storage: files, database, etc.
The layers are higher level abstraction: Each may contain several classes, or several packages
(group of classes).
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 19
UML Package Diagram
Dependency: Represent the “make use of” relationship .
Package: Collection of classes or sub-packages.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 20
Minesweeper: Package Diagram
Presentation
Minesweeper
Application
MSGUI
MSStorage
Storage
Corresponds to programming construct: Java: Package. C++: namespace.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 21
Layered Architecture: Advantages Layers aim to insulate a system from the
effects of change. For example, user interfaces often change:
but the application layer does not use the presentation layer.
so changes to system should be restricted to presentation layer classes.
Similarly, details of persistent data storage are separated from the application logic.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 22
Analysis Class Stereotypes
Within this architecture, objects can have various typical roles: boundary objects: interact with outside actors. control objects: manage use case behaviour. entity objects: maintain data.
These are represented explicitly in UML by using analysis class stereotypes.
Give extra informal information for objects.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 23
Stereotypes can be text or a graphic icon. The icon can replace the normal class box.
Class Stereotype Notation
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 24
Use Case Realization: OverviewUse case realization = implementation of the use case.
Steps: Go through each use case. Identify interaction using a UML sequence diagram. Refine the domain class diagram.
Possible refinements: Adding a new class and/or data. Define association nagivability (direction) and role name. Adding operation to an existing class.
Focus is on System Functionality during Analysis phase. Ignore other layers (Presentation and Storage). Concentrate on the Application layer.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 25
Sequence Diagram UML Diagram to:
Emphasize the interaction in the form of messages. Identify the party involved in the interaction. Outline the timing of the message. Be mainly used in Analysis and Design activities.
Analogy to help you understand: In OO programs, objects interact with each others via method
invocation (method call). Method invocations can be modeled as messages passing
between objects: ObjectA calls method M of ObjectB, is equivalent to ObjectA passes message M to ObjectB.
Sequence Diagram records these message passing.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 26
Sequence Diagram Notation Simpler version of the sequence diagram used in
design activity.
Actor
Class
Entities
Actors or Classes involve in interaction
Lifeline
Message
With parameterMessage ( Para )
Return
Control and possibly value are returned
Activation Bar
Time Passes
Returned value
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 27
Sequence Diagram: Explanation Time passes from top to bottom. Classes and actors at top:
only show those participating in this interaction. each instance has a lifeline.
Messages shown as arrows between lifelines: labelled with operation name and parameters. return messages (dashed) show return of control. activations show when the receiver has control.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 28
Sequence Diagram: Simple Example
class A { public void example( ) { B objB;
int result;
//Sequence diagram shows the //following interaction
result = objB.method(123);
}}
: B
method ( 123 )
: A
Returned 456
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 29
The initial realization consists of: The Staff actor. The System. Message(s) passed between them.
Case Study 1: Use Case Realization
Display Bookings: Basic Course of Events Staff enters a date; System displays bookings for that date.
Take Display Booking use case as example:
Staff sends a message.
System returns results.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 30
Case Study 1: Use Case Realization The domain model shown in Lecture 3 does not contain a System class. The Domain Model only concentrates on entities in
the real world. A new class BookingSystem is added:
An example of domain model refinement. Categorized as a control stereotype:
Receives a high level request from the user. Contacts the relevant classes to fulfill the request.
Boundary stereotype is not appropriate: Emphasizes on the use case behavior, not input/output.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 31
Case Study 1: Sequence Diagram
The display(date) message originates from outside the system (it was called by an external user - Staff): Termed as System Messages (opposite to Internal
Messages, called from an object of the system).
New class added
System Message
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 32
System Sequence Diagram (SSD) Is a Sequence Diagram that shows only
system messages: An informal subtype of sequence diagram. Concentrates on user-system exchange only. Graphical representation of a use case. Serves as a starting point for a more complete
sequence diagram.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 33
Case Study 1: Refining SSD
?
How does the BookingSystem retrieves the bookings? Who should keep track of the bookings? Bad choices:
BookingSystem (why?) Booking (why?)
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 34
Case Study 1: Refining SSD A class to store a collection of Bookings is needed. Adding this ability to BookingSystem is undesirable:
BookingSystem should only handle system messages. Lower the cohesion of the class.
Booking class in domain model: Only records details of one booking. Not a collection.
Hence, another new class is needed: Restaurant class is a reasonable choice. Can take care of other collections:
Tables. Customers.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 35
Case Study 1: Sequence Diagram Ver.1
New Class
New Internal
Message
UI is not the focus at this stage. A
placeholder function.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 36
Case Study 1: Sequence Diagram Ver.1 The sequence diagram tells us:
Staff wants to check a booking for a particular date. BookingSystem receives the request and asks the
Restaurant to provides all bookings on that date. Follow up:
How can Restaurant find the relevant bookings from all bookings record?
One plausible way: Checks the date on each booking record, and collects
only those that match.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 37
Case Study 1: Sequence Diagram Ver.2
* denotes multiple
messages
The Booking class identified in the domain model
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 38
Case Study 1: Display Booking realization At this point, a plausible sequence of messages to achieve
the use case has been identified. The sequence diagram can be used to refine the domain
model. Several key refinements:
New Restaurant and BookingSystem classes with an association between them.
A new association from Restaurant to Booking. Restaurant maintains links to all bookings. Messages sent from restaurant to bookings.
Association from BookingSystem to Booking.• BookingSystem maintains links to currently displayed bookings.• If these were not stored once they had been displayed, then
whenever the display was updated, the current bookings would have to be retrieved again from the Restaurant object.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 39
Case Study 1: Updated Class Diagram (Partial)
New class added
Operation added
New association
added
Association refined
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 40
Refining Association As we move closer to internal representation
of the system, more technical information is needed for association.
Two possible refinements: Add navigability: The arrow above shows only A
can interact with B, but not vice versa. Add role name: A uses rName as the reference
name of B.
A BrName
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 41
Refining Association: Example
The refined class diagram tells us: Only Human is aware of the Mee, i.e.,
Human sends message to Mee, but not the other way around.
Human uses a reference myFood to refer to the instances of Mee, i.e.:
Human MeeEats > 1
Domain Model
Human MeemyFood
Eats > 1
Class Diagram
class Human { Mee myFood;
void method( ) { myFood.cook( );
}}
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 42
Case Study 1: Display Booking realization The Display Booking use case realization is
complete at this point. Review:
Stop at System Sequence Diagram to make sure that every exchange between user and system is modeled.
From the SSD, figure out how entities in domain model can help to fulfill the request.
Add in the appropriate messages. Refine domain model.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 43
Case Study 1: Continuing Use Case Realization
The basic technique has already been explained.
Several Use Case realizations are chosen from Case Study 1 to highlight: Additional notation for Sequence Diagram:
Object Creation/Deletion. Role Name to distinguish objects of the same class.
Other possible refinement to domain model.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 44
Case Study 1: Record Booking realization
Restaurant is responsible for maintaining all bookings. makeReservation() should be handled by Restaurant.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 45
Case Study 1: Record Booking realization Bookings must be linked to Table and
Customer: Restaurant retrieves these with the given identifying
data in booking details. New objects shown at point of creation:
Lifeline starts from that point. Objects created by a message arriving at the
instance, i.e., constructor.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 46
Case Study 1: Creating New Booking Object
New ObjectConstructor Message
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 47
Case Study 1: Cancel Booking realization A three-stage process:
Select the booking to be cancelled. Confirm cancellation with user. Delete the corresponding booking object.
Object deletion represented by a message with a <<destroy>> stereotype. Lifeline terminates with an ‘X’.
Role names used to distinguish the selected object from others.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 48
Case Study 1: Cancel Booking Sequence Diagram
Destruction message
Lifeline Terminated
Role Name
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 49
Case Study 1: Domain Model Refinement Continues
BookingSystem has the responsibility to remember which booking is selected.
Adds an association to record this.
Association Added
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 50
Case Study 1: Record Arrival Realization
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 51
Case Study 1: Record Arrival Realization
Selected Booking must be a Reservation.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 52
Case Study 1: Refining Class Diagram Should setArrivalTime( ) be defined in
Booking or in Reservation class? On the one hand, it doesn't apply to Walk-Ins. But a common interface to all bookings is
desirable. Define operation in Booking class.
Default implementation does nothing. Override in Reservation class.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 53
Case Study 1: Refining Class Hierarchy
Common interface for
all subclasses
Override in
subclass
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 54
Case Study1: Complete Analysis Class Model
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 55
Where are we now?
Requirement
Analysis
Design
Implement
Test
Typical Artifacts: Software Architecture Sequence Diagrams Analysis Class Diagram
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 56
Summary
Analysis has led to: A set of use case realizations. A refined class diagram.
We can see how the class design is going to support the functionality of the use cases.
This gives confidence that the overall design will work.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 57
Reading Suggestions
Chapter 4 of [Bimlesh, Andrei, Soo; 2007] Chapter 5 of [Priestley; 2004]
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 58
Coming up next
Object-oriented design – Chapter 5 of [Bimlesh, Andrei, Soo; 2007]
Design - Chapter 6 of [Priestley; 2004] UML Class and Object Diagrams - Chapter 8
[Priestley; 2004]
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 4 59
Thank you for your attention!
Questions?