310414 : Software EngineeringLEARNING OBJECTIVES
1. Understand the role and importance of system analysis in the
software development process.
2. Know the major activities that take place during system
analysis.
3. Learn how to transform a use-case model into a form that is
maintainable.
4. Learn how to represent the interactions among the objects that will realize a use case.
5. Learn how to describe the internal behaviour of objects and the
flow of control among objects.
310313
Life Cycle Role
Analyze Use Cases
Phases
SYSTEM ANALYSIS:WORKERS
architect - responsible for the architecture description and the integrity of the analysis model; ensures that the analysis model is correct, consistent and readable
use-case engineer - responsible for the integrity of one or more use-case realizations ensuring that they fulfill their requirements
component engineer - defines and maintains the responsibilities, attributes, relationships and special requirements of one or more analysis classes
310313
SYSTEM ANALYSIS:ARTIFACTS
analysis model - a conceptual object model that refines the requirements and structures them so that they are more precise and maintainable
architecture description - an architectural view of the analysis model depicting its architecturally significant artifacts
use-case realization—analysis - describes how a specific use case is realized and performed in terms of analysis classes and their interacting analysis objects
analysis class - handles functional requirements; one of three basic stereotypes: boundary, control or entity
analysis package - provides a means of organizing the artifacts of the analysis model into manageable pieces
310313
SYSTEM ANALYSIS
Goal: structure the use-case model into a form that is both robust and maintainable during the system’s life cycle
5.1
We assume an ideal implementation environment
do not consider: hardware, DBMS, programming language, etc. as these are likely to change over the system’s life cycle
We specify all the (dynamic) logical classes in the system and how they are related and grouped (into packages)
We distribute the behaviour of the use-case model among the (logical) classes of the analysis model
We specify explicitly which class in the analysis model is responsible for which behavior in the use-case model
310313
The benefits of an analysis model are that it:
yields a more precise and complete specification of the requirements ® removes ambiguities and redundancies
is described in the developers language ® more formal/precise
structures requirements for easier understanding and maintenance
is a first cut at design
What do we do with the analysis model?
keep and maintain it throughout the system’s life cycle
throw it away after analysis is complete
don’t do it! (not recommended)
310313
Use cases structure the external view
Used primary as acontract between client/developer to agree on system functionality
May contains ambiguities, redundancies, inconsistencies, etc.
Captures system functionality
Defines use cases
Analysis classes and packages structure the internal view
Used primary by developers to understand how to design and implement the system
Contrain no ambiguities, redundancies, inconsistencies, etc.
Outlines system realization
Defines use-case realizations
Analyze use cases
identify analysis classes
specify interactions among analysis objects
capture special requirements (nonfunctional)
describe any nontrivial behaviour of classes/objects
capture special requirements (nonfunctional)
5.2
310313
USE CASE ANALYSIS : ANALYSIS CLASS
An analysis class is an abstraction of one or several classes in the final system implementation
class descriptions are conceptual, not implementation oriented
attributes: types are conceptual, not programming language types
behavior: defined by textual descriptions of responsibilities
relationships: conceptual, not implementation oriented
classes are one of:
boundary – entity – control
(system design usually has many more classes — up to 5 times)
focuses on handling functional requirements only
310313
ANALYSIS CLASS — BOUNDARY CLASS
Interacts with actors outside the system as well as with classes within the system
Represents an abstraction of UI elements (windows, forms, panes, etc.) or devices (printer interfaces, sensors, terminals, etc.)
The description should be kept on a fairly high conceptual level DESCRIBE WHAT NOT HOW
(i.e., do not describe every button, menu item, etc. of a UI!)
Models the interaction between
«boundary»
boundary
5.3; 5.4
Usually found from use case descriptions ® start from actors
identify forms and windows needed to enter data into the system
identify notices and messages the systems uses to respond
do not model the visual aspects of the interface
always use the user’s terms for describing interfaces
5.4.2
Initial, dentify one boundary class for each actor/use case pairr
For human actors it represents the primary UI window with which the actor interacts
For externals system,it represents the communication interface to the external system
Initial boundary classes can later be aggregations
to or become aggregationsof other boundary classes
310313
ASU : USE-CASE DETAILED SPECIFICATION
Select courses to teach
This use case describes how a professor selects courses to teach for a semester that has not started.
Actors
Basic Path
1. The use case starts when the professor selects the option Select courses to teach.
2. The system displays the interface for selecting courses to teach.
3. The professor enters the semester and year in which he would like to teach courses. (A1)
4. While the professor has an activity to perform
4.1. If the CREATE activity is selected (A2)
4.1.1. The S1: Create a schedule subflow is performed.
4.2. If the REVIEW activity is selected (A3)
4.2.1. The system retrieves and displays the professor’s teaching schedule.
4.3. If the MODIFY activity is selected (A3)
4.3.1. The S2: Modify a schedule subflow is performed.
5. The use case ends.
310313
S1: Create a schedule
1. The system checks that the final date for changes has not passed. (A4)
2. The system retrieves and displays the available course information for the given semester.
3. The professor selects the courses that he would like to teach.
4. The professor confirms the selection. (A5)
5. The system creates the professor’s teaching schedule in the database.
6. The system notifies the professor that the request has been processed.
S2: Modify a schedule
1. The system checks that the final date for changes has not passed. (A4)
2. The system retrieves and displays the professor’s teaching schedule and the available course
information for the given semester.
3. While the professor wants to add a course
3.1. The professor indicates which further section to teach.
3.2. The system displays the updated teaching schedule for the given semester.
4. While the professor wants to delete a course
4.1. The professor indicates which section not to teach.
4.2. The system displays the updated teaching schedule for the given semester.
5. The professor confirms the changes. (A5)
6. The system updates the professor’s teaching schedule in the database.
7. The system notifies the professor that the request has been processed.
310313
Request enrollment list
CreateScheduleUI
ReviewScheduleUI
ModifyScheduleUI
SelectCoursesUI
RequestEnrollmentUI
ProfessorUI
310313
5.3.1; 5.4.1
represents concepts such as an individual, a real-life object or a real-life event
Models information that is
long-lived and often persistent
class name
An entity class will likely be implemented as part of a database
(but, represents a dynamic object in the analysis model)
encapsulates and isolates changes
Specification strategy
entity class name
Examine the use case to
determine what domain
usually does not have a correspondence in the application domain
A control class provides the “glue” that ties other classes together into one use-case realization
Use to present:
Control relate to a specific use case.
Business logic (e.g., complex derivations and calculation).
a control class should only be tied to at most one actor
Models coordination, sequencing,
«control»
control
5.3.1; 5.4.3
Specifification strategy
Initially, we assign one control class for each actor/use case pair (and for each «include»/«extend» use-case) that is responsible for the flow of events in the use case.
Complicated behavior may need several control classes.
May also combine/eliminate some control classes.
A control class should only be tied to at most one actor!
WHY?
Changes in system requirements are often initiated from actors.
By associating a control class with at most one actor, we isolate changes required to only the functionality required by that actor.
Note: Sometimes it is better to encapsulate the control in the boundary
class especially if the actor handles large parts of the control.
Handle
later!
310313
310313
Assign one control class for
each actor/use case pair.
control and entity classes?
DISCOVERING ANALYSIS CLASSES/INTERACTIONS
How can we discover the analysis classes needed for a use case and the interactions among them?
scenario: a use case instance (one path through the flow of events)
scenarios help identify the objects and interactions that are needed to carry out the functionality specified by a use case
interaction diagram used to capture the
objects and the interactions among them
two types of interaction diagrams:
collaboration diagrams
sequence diagrams
Actors can interact only with boundary classes
Entity classes can interact only with control classes (initially)
(Later we will see they can also interact with boundary classes)
Control classes can interact with boundary, entity and other control classes
Boundary classes can interact only with control classes and actors (initially)
(Later we will see they can also interact with entity classes)
These practices result in a well structured and maintainable system.
boundary class
boundary class
entity class
entity class
COMMUNICATION DIAGRAM
Shows the objects involved and the messages that flow between the objects to carry out a use-case scenario
1: set course info
COMMUNICATION DIAGRAMS (cont’d)
show how object classes are linked together to form a use case and the messages that flow between the objects of the classes
messages
sequence indicated by numbering of messages
(messages from actors can be left unnumbered)
a nested message is a message that is sent while another message is still active (i.e., control has not returned to the sender)
nested messages are numbered using decimal numbering scheme (e.g., 1.1, 1.2, etc.) (Note that Rose 98 does not support decimal numbering)
guard condition - indicates conditional sending of a message
® message is only sent if the condition is true
iteration marker * - indicates that a message is sent repeatedly; iteration expression can be: [i = 1..n]; [while (boolean expression)]; [until (boolean expression)]; [for each (collection expression)]
310313
use separate diagrams for complex behavior
flow of events—analysis –> written in terms of objects, particularly control objects, that interact to perform the use case
{new} created during execution
{destroyed} destroyed during execution
special designations for objects
310313
SELECT COURSES TO TEACH (CREATE A SCHEDULE)
We create the communication diagram by considering the flow of events for the Create a schedule scenario of the Select courses to teach use case while keeping in mind the best practices for representing interactions.
The use case is started by the professor selecting the option Select courses to teach through the ProfessorUI role (Line 1 of the Select courses to teach use case).
The ProfessorUI role (Message 1) then displays the interface for selecting courses (Message 2) (Line 2 Select courses to teach use case).
After the professor enters the semester and year (Message 3) (Line 3 Select courses to teach use case), the course information for selection needs to be retrieved (Message 4).
However, before retrieving the course information, we first need to check if the deadline for making changes for the current semester has passed (Line 1 of the Create a schedule subflow).
310313
SELECT COURSES TO TEACH (CREATE A SCHEDULE)
The question now arises, where do we check the semester deadline information? According to the current design of the domain model (see System Requirements Capture notes), the semester information is kept in the CourseOffering class. Therefore, we need to check an object of this class for the current semester.
However, at this point we realize that it is probably not appropriate to keep this information in the CourseOffering class since this means that every CourseOffering object instance will need to hold this information, which
introduces a lot of data redundancy!
Accordingly, we identify a new class, Semester, into which we place the semester information including the deadline information. (Note that this will cause an update to the domain model for the ASU System as shown on the following slide.)
310313
310313
SELECT COURSES TO TEACH (CREATE A SCHEDULE)
Having made the deadline check (Message 4.1), we now retrieve the course
information (Messages 4.2, 4.3 and 4.4) and display it to the professor
(Message 5) (Line 2 of the Create a schedule subflow). In the process, we
have identified another new class that is needed, Section, since a course
offering can have several sections and it is a section that is the unit for teaching assignments. (This also will cause an update to the domain model.)
The professor makes his selection (Message 6) and confirms it (Message 7)
(Lines 3 and 4 of the Create a schedule subflow).
The system creates the teaching schedule (Message 8), which requires that the objects playing both Section (Message 8.1) and Professor (Message 8.2) rolesbe updated since the relationship is bi-directional in the domain model (i.e., a Section object needs to have a reference to the Professor object and a Professor object needs to have a reference to the Section object(s)) (Line 5 of the Create a schedule subflow).
Finally, the status of the request is displayed to the professor (Message 9) (Line6 of the Create a schedule subflow) and the use case ends.
310313
310313
310313
Further analysis
The preceding communication diagram is incorrect in at least one aspect.
If we consider the (revised) domain model class diagram, we notice that the course offerings are semester specific, that is, they can be related to only one semester.
Thus, before actually retrieving the course information from the objects playing the CourseOffering, Course and Section roles, we first have to establish which are the course offerings for the current semester.
From the revised domain model class diagram, we see that a Semester object knows about the CourseOffering objects to which it is related.
Thus, we need to add one more interaction to the communication diagram (Message 4.2: Get semester offerings) before actually retrieving the course information.
Consequently, we obtain the following revised communication diagram.
Note that this communication diagram is still not completely correct, but we will fix it later.
310313
310313
Scenario of creating a teaching schedule in a given semester
1. The Professor role asks the ProfessorUI role to let the professor maintain his teaching schedule (1).
2. Since the default mode is “Create”, the ProfessorUI role displays the schedule creation form for the professor to select courses to teach (2).
3. The professor specifies the semester and year for which the teaching schedule is to be maintained through the ProfessorUI role (3).
4. The ProfessorUI role asks the SelectCoursesToTeachMgr role to retrieve the available teaching section choices for the professor to choose (4).
5. After checking that the deadline for modification has not passed (4.1), the SelectCoursesToTeachMgr role gets the available teaching section choices from the Semester, Course, CourseOffering and Section roles (4.2, 4.3, 4.4, 4.5).
6. The ProfessorUI role displays the available offering sections (5).
7. The professor selects sections of courses to teach through the ProfessorUI role(6).
8. The professor confirms the schedule through the ProfessorUI role (7).
9. The ProfessorUI role informs the SelectCoursesToTeachMgr role to make corresponding updates (8) on the Section and Professor roles (8.1, 8.2).
10. The ProfessorUI role informs the professor of the status of his request (9).
310313
lifeline
relative
time
roles go across horizontally and can be named or anonymous
first column –> the actor who initiates the use case
second column –> a boundary object (that the actor uses to initiate the use case) [may be more than one]
third column –> the control object that manages the use case
time axis goes downward
not linear, but should be regarded as event controlled;
distance between two events has no relation to real time between these events;
shows precedence, not actual time
lifeline of an object is represented by a vertical dashed line
order among lifelines is not significant
all behaviour of an object will be attached to its lifeline
310313
SEQUENCE DIAGRAMS (cont’d)
messages are named and represented by (solid head) arrows that point from sender to receiver
order of messages is shown from top to bottom
return value (open head, dashed) arrow is optional and is usually omitted
mark the lifeline to which a message is sent with a rectangle
representing the operation
self-delegation (a message an object sends to itself) is shown by sending the message arrow back to the same lifeline
can also include the following control information:
guard condition: indicates condition under which a message is sent
iteration marker: shows that a message is sent many times to multiple receiver objects (e.g., iterating over a collection)
310313
310313
Start scheduling process
Add courses to teach
Get available courses
Update teaching schedule
Update teaching schedule
310313
Further analysis
For the communication diagram constructed previously, consider access to CourseOffering and Section objects.
To retrieve all CourseOffering and Section objects for a given semester, we actually need to iterate to get all offerings (Message 4.3) and all sections for a course (Message 4.3.2) as shown in the revised communication diagram on the next slide.
Also note that we first need to retrieve the CourseOffering objects before we can retrieve the relate Course object since Semester objects know only about their related CourseOffering objects according to the domain model.
Furthermore, when we create the professors schedule, we may need to update several Section objects (Message 8.1) and thus also need to iterate.
Accordingly, we also need to revise the sequence diagram to show this behaviour.
310313
310313
310313
Scenario of creating a teaching schedule in a given semester
1. The Professor role asks the ProfessorUI role to let the professor maintain his teaching schedule (1).
2. Since the default mode is “Create”, the ProfessorUI role displays the schedule creation form for the professor to select courses to teach (2).
3. The professor specifies the semester and year for which the teaching schedule is to be maintained through the ProfessorUI role (3).
4. The ProfessorUI role asks the SelectCoursesToTeachMgr role to retrieve the available teaching section choices for the professor to choose (4).
5. The SelectCoursesToTeachMgr role checks that the deadline for modification has not passed (4.1).
6. The SelectCoursesToTeachMgr role gets the available course offerings for the semester from the Semester role (4.2).
7. For each course offering in the semester
7.1. The SelectCoursesToTeachMgr role retrieves the CourseOffering role (4.3).
7.2. The SelectCoursesToTeachMgr role retrieves the Course role (4.3.1).
310313
(4.3.2).
8. The SelectCoursesToTeachMgr role assembles and formats the course offering information.
9. The ProfessorUI role displays the available offering sections (5).
7. The professor selects sections of courses to teach through the ProfessorUI role(6).
8. The professor confirms the schedule through the ProfessorUI role (7).
9. The ProfessorUI role informs the SelectCoursesToTeachMgr role to add the course sections to the professors teaching schedule (8).
10. For each section added to the teaching schedule
10.2.The SelectCoursesToTeachMgr role asks the Section role to update its teaching schedule(8.1).
11. The SelectCoursesToTeachMgr role asks the Professor role to update its teaching schedule(8.2)
12. The ProfessorUI role informs the professor of the status of his request (9).
310313
SEQUENCE DIAGRAMS — CONCURRENCY
When a Transaction is created it creates a Coordinator to manage the checking.
The Coordinator creates a series of Checkers, one for each kind of check. These Checkers do their checks as separate processes
If a given check fails, the Coordinator kills all other Checkers that are still running and tells the Transaction that it is invalid.
X
X
new
new
new
new
killCheckers
aTransaction
fail
beInvalid
kill
X
aTransaction
Coordinator
afirst
Transaction
Checker
asecond
Transaction
Checker
: Actor
synchronous - sender loses control until the receiver finishes handling the
message
asynchronous - the message does not expect a reply; the sender stays active and
may send further messages
message naming
should clearly indicate what action the invoking class requires
reusability
does assigning a message to a class make it more or less reusable?
applicability
is the message a good fit with the class (relevant to the class)?
complexity
in which class is it easier to implement a message?
creating new objects
310313
SEQUENCE DIAGRAM NOTES
a hard to read sequence diagram is, for all practical purposes, of no use
the sequence should be visible — and reviewable
deciding which operations go on which classes is the purpose of drawing sequence diagrams
experience and talent are required here!
There is no single “right” answer!
There are many ways to create a design and end up with working code.
310313
communication diagrams
provide the big picture for a scenario, since they are organized around how objects link to one another
used to determine class relationships
sequence diagrams
provide a way to look at a scenario in time-based order — what happens first, what happens next, etc.
used to determine message ordering
Collaboration and sequence diagrams are isomorphic
(Rational Rose can create one from the other)
310313
SEQUENCE DIAGRAM EXAMPLE
The domain model, showing the navigability of the associations, and the Reserve video (staff scenario) use-case description for the video sales and rental shop application are given below. Using only one boundary class, one control class and any of the domain model entity classes, construct a sequence diagram that shows the objects required to realize this use case and the messages that are passed among the objects.
Buys
quantity
Has
Reserve video (staff scenario)
This use case allows a staff to reserve up to 5 videos at a time for a member.
Actors
Preconditions
1. The staff has successfully logged on to the system and the member has less than 5 videos reserved.
Basic Path
1. The use case begins when the user selects Reserve a video.
2. The system prompts the staff to input the member number and the video ID.
3. The staff inputs the member number and the video ID.
4. The system reserves a copy of the video for the member.
5. The use case ends.
310313
The interactions in the sequence diagram are created as follows:
The use case is started by the Staff actor selecting Reserve a video through the ReserveVideoUI (Message 1) (Line 1 of Reserve Video use case).
The ReserveVideoUI displays the screen for entering the member number and the video ID (Message 2) (Line 2 of Reserve Video use case).
The staff enters the member number and the video ID (Message 3) (Line 3 of Reserve Video use case).
The ReserveVideoUI asks the ReserveVideoMgr to reserve the video for the member (Message 4) (Line 4 of Reserve Video use case).
To reserve the video, the ReserveVideoMgr does the following:
First, it needs to get a reference to the member by searching through Member using the provided member number (Message 5). (Note that we are given a member number, not a reference to a Member. Thus, we need to use the member number to find the corresponding (object) reference. Since this is the normal path for the use case we can assume that this search succeeds and we get the appropriate reference.)
Next, it needs to get a reference to the desired movie video by searching through MovieVideo using the provided video ID (Message 6).
310313
SEQUENCE DIAGRAM EXAMPLE:SOLUTION
(Again note that we are given a video ID, not a reference to a MovieVideo. Thus, we need to use the video ID to find the corresponding (object) reference. Since this is the normal path for the use case we can assume that this search succeeds and we get the appropriate reference.)
– Having obtained the reference to MovieVideo, the ReserveVideoMgr next needs to get the references to its related rental copies (Message 7).
– Next, the ReserveVideoMgr needs to find (a reference to) an available rental copy. (Note that a rental copy may already be rented or reserved.) It does this by searching through RentalCopy until an available copy is found. (Again, since this is the normal path for the use case we can assume that this search succeeds and we get the appropriate reference.)
Finally, the ReserveVideoMgr needs to inform both the RentalCopy (Message 9) and the Member (Message 10) about the reservation (i.e., give them a reference to each other) since the association is bi-directional in the domain model.
Although not specified in the use case, it is reasonable to assume that the ReserveVideoUI informs the staff about the status of the reservation request (Message 11).
The use case ends (Line 5 of Reserve Video use case)
310313
SEQUENCE DIAGRAM EXAMPLE:SOLUTION
Flow of events for Reserve video (staff scenario) Use Case—Analysis
1. The Staff asks the ReserveVideoUI to allow a staff to reserve a video.
2. The staff enters the member number and the movie ID.
3. The ReserveVideoUI asks the ReserveVideoMgr to reserve a copy of the indicated video.
4. The ReserveVideoMgr searches Member to get a reference to the role whose member# equals the input member#.
5. The ReserveVideoMgr searches MovieVideo to get a reference to the role whose movieID equals the input movieID.
6. The ReserveVideoMgr gets the list of rental copies for the movie from MovieVideo.
7. The ReserveVideoMgr searches through the list of rental copies for an available one.
8. The ReserveVideoMgr asks the available Rental to reserve itself for the member.
9. The ReserveVideoMgr informs the Member of the new reservation.
310313
Notes:
1. Since we are only given the movieID as an input value, we need to identify the rental copies for a movie via its associated MovieVideo role, which knows about all of its rental copies by way of the association Has between MovieVideo and RentalCopy.
2. Since not all copies of a video may be available for rental (either rented already or reserved), we need to search for an available copy. Since this is the basic path, we assume that the search succeeds in finding an available copy.
3. There is no need to check how many videos a member has reserved as the precondition states that he has less than 5 reserved.
4. Since the navigability of the Reserves association is bi-directional, it is necessary for the Member role to be informed of the fact that a new video has been reserved and which copy has been reserved.
310313
System” is not a role in a communication/sequence diagram.
We need to think object interaction, not procedural programming.
We need entity roles if we want to access (database) data.
Entity roles do not interact with other entity roles (see Best Practices slide).
The messages:
do not describe UI elements (e.g., textbox).
do not originate from entity roles.
are sent to only one instance of a role.
are named from the perspective of what the sending role wants the receiving role to do for it.
310313
PRINCIPLES OF USE CASE PARTITIONING
Each use case is entirely divided up into a collaboration of:
boundary classes ® functionalities directly dependent on the system’s environment
entity classes ® functionalities dealing with storage and handling of information which are not naturally placed in any boundary class
control classes ® functionalities specific to one or a few use cases and not naturally placed in boundary or entity classes
Goal: achieve localization of changes
so as to result in a stable system
In practice we need to make many judgments
about where to place the functionality
310313
Use-Case Model
Analysis Model
From roles that a class plays in each use-case realization
Consider:class diagrams, collaboration/sequence diagrams, flow of events (can use CRC cards to help discover responsibilities)
Identify attributes for each analysis class
boundary classes items manipulated by actors
entity classes from domain model
control classes rarely have attributes; usually temporary values
as much as can be inferred now from use-case descriptions
Identify associations, aggregations, generalizations
from shared and common behaviour among analysis classes
Note: Not real-world relationships, but relationships that must exist
in response to demands of various use-case realizations.
310313
3”x5”
required to carry out
operations on the class)
310313
by examining all of the communication/sequence diagrams
for the use case in which the class plays a role.
310313
A state machine diagram describes the behavior inside an object
(what an object does when it receives a message)
It is a directed graph that shows:
the states of a single object (nodes)
the events or messages that cause state changes (arcs)
the actions that result from a state change
It shows all the messages that an object can send and receive
It describes all the possible states an object can get into during its life time
It is drawn for a single class to show the lifetime behavior of a single object
2.4.4; 5.4.7
Setup
InCredit
Closed
Overdrawn
after(5 years)
[balance<0]
STATE MACHINE DIAGRAM — STATE
A time during the life of an object when it satisfies some condition, performs some action or waits for an event
A state may be characterized by:
value of one or more attributes of the class (e.g., BankAccount can be InCredit or Overdrawn based on the value of balance attribute)
existence of a link to another object (e.g., in ASU example ProfessorInfo object may be teaching or not based on existence of a link to a Section object)
Can discover object states from sequence diagrams
A state has duration
initial state (start state)
each diagram must have one and only one initial state
final state (end state)
States may be named
310313
STATE MACHINE DIAGRAM — TRANSITION
A Transition is a change of state from an originating state (source state) to a successor state (target state)
The source and target states may be the same state
A transition takes zero time and cannot be interrupted
trigger - the (implicit) event that causes a transition to occur
an event triggers a transition; the transition is said to fire
Transition adornments (all are optional):
event signature ® event name plus optional parameters
guard condition ® Boolean expression which must be true
Effect list ® an atomic procedural expression executed when
transition fires
310313
Something that happens at an instantaneous point in time
call event – the receipt of a message from an object requesting that an operation be performed
change event – a special boolean condition becoming true
® when(balance < 0)
– elapsed time ® after(10 seconds)
signal event – the receipt of an asynchronous communication from an object
Two events may be:
causally related ® one has to occur before the other (sequential)
unrelated ® can occur simultaneously (concurrent)
E
v
e
n
t
t
y
p
e
s
310313
Events are processed one at a time
if the event does not trigger any transition it is ignored
Only one transition within a (sequential) statechart diagram may fire
if two transitions can fire, then the choice may be nondeterministic (i.e., a race condition)
All transitions leaving a state must correspond to different events
There two ways to transition out of a state:
automatic - when the activity of the state completes
Transitions without labels fire immediately
when the state activity , if any, completes
non-automatic - caused by an event
310313
possible forms of state behavior:
no behavior ® wait until an event occurs that exits the state
event name [guard condition] / action ® when event occurs and condition is true, action is performed
do / activity ® calls an operation or calls another statechart diagram
entry / activity ® atomic action performed on entering the state
exit / activity ® atomic action performed on exiting the state
action - instantaneous and cannot be interrupted
Processing for transitions between states and entry/exit of a state.
activity - takes time to complete and can be interrupted
Processing that occurs while in a state
310313
310313
ASU — COURSE REGISTRATION PROBLEM STATEMENT
At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as instructor, department, and prerequisites are included to help students make informed decisions.
The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or is canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester.
Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings.
For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses.
310313
STATE MACHINE DIAGRAM EXAMPLE
Part of the information kept in the RentalCopy class in the domain model shown below is the rental status of a video. Construct a statechart diagram showing the states that an instance of the RentalCopy class can be in with respect to its rental status. Show only the states, transitions and the events and/or conditions, if any, that cause a transition to be taken. Do not show the activities that can occur within a state.
Buys
quantity
Has
Problem statement requirements relevant to determining the states of a
RentalCopy object:
– The system must be able to keep track of which movie videos have been
bought/rented and by whom. For videos bought, the system must record
the quantity bought; for videos rented, the system must record which
copy of the video has been rented and when it is due back.
– The system must keep track of overdue rental videos and allow notices
to be sent to customers who have videos overdue.
– Members should be able to make reservations for movie video rentals
either in person at the store, by telephone or via the Web.
– A member can reserve at most five movie videos at any one time, but
there is no limit on how many movie videos a member or nonmember
can rent at any one time.
– Staff must be able to sell/rent videos from the stores inventory and
return rented videos to the store's inventory.
310313
COMPOSITE STATE MACHINE DIAGRAM
A composite state machine diagram that has one or more nested state machine diagram
sequential composite state machine diagram
An object is in exactly one state in one of the statechart diagrams
corresponds to an or-condition on all statemachinet diagrams
It is used to abstract/generalize states
concurrent composite state machine diagram
An object is in exactly one state in each of the state machine diagrams
corresponds to an and-condition on all state machine diagrams
It is used to show multi-threading behavior
Invoked by - do / state machine-diagram-name (argument-list)
310313
Neutral
Reverse
CONCURRENT COMPOSITE STATE MACHINE DIAGRAM
arises when an object can be partitioned into subsets of attributes or links, each with its own statechart diagram
Result of Taking A Class
Passed
Failed
Incomplete
fail
Incomplete
Passed
Take
Exam
pass
Term
Project
A transition to boundary transition to initial state
Entry actions of all regions entered are performed
There may be transitions directly into a composite state region
A transition from the boundary transition from the composite state
Exit actions of all regions exited are performed
There may be transitions directly from within a composite state region to an outside state
A transition may have multiple source and target states
Synchronization/splitting of control
Concurrent state 1
Concurrent state 1
CONCURRENCY AMONG STATE MACHINE DIAGRAMS
The state change of an object may depend on the state that
another object is in.
– It may be necessary to specify interactions among the states of
different objects.
guarded transitions
– A transition in one object can depend on another object being in a
certain state.
message sending
– An object can send a message to another object to cause it to
change state.
WHEN TO USE STATE MACHINE DIAGRAMS
A state machine diagram is good at describing the behavior of an object across several use cases
it is not necessary to produce statechart diagrams
for every class
A state machine diagram should be used only for classes with significant dynamic behavior
sequence diagrams can be studied
to discover objects with significant dynamic behavior.
boundary and control classes are good candidates
310313
ACTIVITY DIAGRAM
An activity diagram shows either workflow among several objects of a use case or flow of control for an operation of an object
variation of a statechart diagram
It can describe procedural logic, business process or work flow
It is essentially a flowchart but also allows concurrency
It shows the flow of activities, but not the objects
It can be attached to the specification of
An operation to show the procedural logic
A use case to show the work flow among object
2.4.5
310313
activity diagram
represents states of the executing computation
interaction diagram
shows flow of control from object to object
310313
Process Order use case
When we receive an order, we check each line item on the order to see if we have the goods in stock. If we do, we assign the goods to the order. If this assignment sends the quantity of those goods in stock below the reorder level, we reorder the goods. While we are doing this, we check to see if the payment is O.K. If the payment is O.K. and we have the goods in stock, we dispatch the order. If the payment is O.K., but we do not have the goods, we leave the order waiting. If the payment is not O.K., we cancel the order.
310313
Order
dateReceived
isPrepaid
number
price
dispatch()
close()
Customer
name
address
creditRating()
OrderLine
quantity
isSatisfied
Item
description
price
stockQuantity
Places
1
<<iterative>>
Receive
Order
Reorder
Item
Dispatch
Order
Check
Line
Item
ACTIVITY DIAGRAM :ACTION NODE
An action node represents either the execution of a statement in a procedure or the performance of a step in a workflow.
It is labeled with action expression
An action may be described by:
natural language – another activity diagram
An action may only use attributes and links of the owning object
We need to identify which object does this activity
It represents states of the executing computation/workflow not an object
310313
A control flow is an edge between nodes that specifies
a sequencing constraint on the execution of nodes.
A control flow normally results from the completion of the action
of a node.
A node can only begin execution after all of the nodes of its
incoming edges have completed execution.
A control flow may include a guard condition.
310313
(There may be multiple initial nodes there is concurrency.)
final node – indicates where execution stops.
activity final node terminates all activity
flow final node terminates one thread of activity
decision – indicates the start of conditional behaviour (a branch)
Each outgoing edge should be labeled by a guard condition.
All possible outcomes should be specified on one of the outgoing edges.
merge – indicates the end of conditional behaviour
310313
activity starts.
A fork has one input edge and multiple output edges.
The number of outgoing edges determine the amount of concurrency.
join – indicates a point at which independent, concurrent
activities have to wait until the nodes of all incoming
edges have completed processing.
A join has two or more input edges and one output edge.
310313
occur once for each item in an input collection.
It is a mechanism to apply a computation repeatedly to each of
the elements within a collection.
It can have one of three execution styles (shown in the upper
left corner of the region):
parallel – the inputs are processed in parallel.
iterative – the inputs are processed one at a time in order.
stream – the inputs are available simultaneously for processing.
If an expansion region has an output, it must be the same kind of collection of values that was input.
310313
dead end action - not all outcomes have outgoing edges
– A dead end action is O.K. on non-terminating activity diagrams.
– It means that not all processing has been specified.
– Another activity diagram may take over the processing.
Example Replenish Supply use case
When a supply delivery comes in, we look at the outstanding
orders and decide which one we can fill from this incoming
supply. We then assign each of these to its appropriate orders.
Doing this may release those orders for dispatching. We put the
remaining goods into stock.
Receive
Supply
Choose
Outstanding
ACTIVITY DIAGRAM : SIGNAL
A signal is the receipt of an event from an outside process.
send signal – (e.g., sending a message)
accept signal – (e.g., waiting for a message)
time signal – indicates the occurrence of the
passage of time
1. Throw an exception
We often group statements that can throw exceptions (e.g., “try” block
in VB.NET).
This is called a protected node in an activity diagram.
2. Catch the exception and perform some action
E.g., “catch” block
This is called the handler body in an activity diagram.
If an exception occurs, the set of handlers is examined for a
possible match. If a match is found, the handler body is
invoked, and the handler catches the exception. If the exception
is not caught, the exception is propagated to the enclosing
protected node if one exists.
310313
310313
The responsible entity may be is a:
use cases
roles
To show partitions, it is necessary to arrange activity activity diagram into vertical zones (swimlanes) (This may not be easy!)
Each action is assigned to one partition (swimlane)
Control flows usually cross partition boundaries
310313
Register for a course procedure
A student can register for a course if he has taken the prerequisites. However, he may not register for a course if he has already taken a course that is an exclusion. A student who does not have the prerequisites can register for a course if he is currently registered in the prerequisite course and has the permission of the instructor. Notwithstanding the preceding, the instructor may waive the prerequisite for a student.
310313
Check
enrollment
[closed]
Abort
registration
Check
pre-
requisites
Check
exclusions
Check
permission
Register
1.To show the procedural flow of control of an operation.
In this case, all or most of the actions represent the computation of the operation.
2. To show workflows and multi-threaded programs.
In this case, the activity diagram shows the steps of a use case, possibly with parallel behavior.
Each activity must be expanded as one or more
operations (actions) assigned to a specific class
310313
some criteria for allocating uses cases to packages include:
required to support a specific business function
required to support a specific actor
related via generalization and extend relationships
one possible starting point: place a control class in a package and then any “strongly coupled” entity and boundary classes
A mechanism used to group analysis classes for ease of use, maintainability, and reusability
Goal: localize changes to the system
2.4.6
package
name
310313
PACKAGE DEPENDENCY
if changes in one package may cause changes to the other or if one package is needed by the other to carry out its functionality
for shared classes, we can:
place it in its own package
place it just outside all packages
and let other packages depend on it
Consider
navigability
package
B
package
A
package
A
PACKAGE DEPENDENCY (cont’d)
an element in the client uses an element in the supplier in some way
–> the client depends on the supplier (general form of dependency relationship)
the namespace of the supplier is added to the namespace of the client
–> elements in the client can access all public elements in the supplier
elements in the client can access all public elements in the supplier but namespaces are not merged
–> the client must use pathnames
usually represents an historical development of one element into another more developed version
supplier
client
supplier
client
supplier
client
analysis
model
design
model
«use»
«import»
«access»
«trace»
310313
all element names in the package must be unique
to refer to an element in a different name space, may need to specify (depending on package dependency):
the name of the element
the pathname to get to it (e.g., Package1::Package2::classname, etc.)
Note: «access» and «import» are not transitive
C
B
A
«import»
«import»
310313
+ public - visible to other packages
- private - not visible to other packages
# protected - only visible to child packages
Goal: minimize the number of public and protected package elements
maximize the number of private package elements
ensures that a package has a small, simple interface
310313
(7 ± 2 heuristic)
cohesion - a measure of the number of functionally different things a package has to do
a package is most cohesive when it does only one thing
coupling - a measure of the number and types of interconnections (dependencies) a package has with other packages
a package has the lowest coupling when it has minimal dependencies with other packages
310313
logical - everything related to output
temporal - all must be executed at the same time
procedural - parts related and must be executed in a given order
communicational - parts process one area of a data structure
sequential - output from one part is input to another part
functional - performs one distinct procedural task
coincidental
logical
temporal
procedural
communicational
sequential
functional
High
Low
COHESION
coincidental - the elements of the package cannot be seen as achieving any definable function
logical - several similar, but slightly different functions are put together
temporal - packages that contain a variety of functions that happen to be executed at the same time
procedural - functions that must be executed in a pre-specified order
communicational - all processing elements of a package operate on the same data stream or data structure
sequential - the out from one part of a package is input to the next part
functional - package has one and only one identifiable function
310313
data - argument list passed
stamp - portion of a data structure is passed as an argument
control - control is passed (e.g., a flag)
external - package tied to an environment external to the software
common - use of a global data area
content - makes use of data/control information in another package
no direct
COUPLING
no direct - packages are not related (except maybe called by some packages)
data - packages pass only simple data (e.g., parameter list)
stamp - a portion of a data structure is passed
control - control is passed between packages (e.g., via a flag.switch on which decisions are made)
external - packages are tied to an environment external to the software system (e.g., I/O couples a package to specific devices)
common - a number of packages reference a global common data area
content - one package makes use of data or control information maintained within another package
310313
organize analysis packages into partitions and layers
application-specific: the part of the system that is not shared by other packages
application-general: the part of the system that is reusable within a business or application domain
Application-specific layer
Application-general layer
Application-specific layer
Application-general layer
Layer Package
Application-specific layer
Application-general layer
Partition Information
Maintenance functionality
Application-specific layer
Application-general layer
Partitions use cases into boundary, control, entity classes.
activity diagrams – show the overall workflow among objects of a use case, especially concurrency
communication/sequence diagrams – show how each use case is realized by objects and message sequencing
Class analysis
Package analysis
310313
Localizes changes to business processes, actor’s behavior,
or closely related use cases
analysis classes, their responsibilities, attributes, relationships and special requirements
Localizes changes to boundary, entity, or control classes
use-case realizations — analysis
architectural view of the analysis model
Localizes changes to architecture
System Analysis Specification (SAS)