310313 SOFTWARE ENGINEERING SYSTEM ANALYSIS.

SOFTWARE ENGINEERING SYSTEM ANALYSIS

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

SYSTEM ANALYSIS OUTLINE
System Analysis and Unified Process Overview Life Cycle Role Importance of System Analysis Unified Process System Analysis Activities Analyze Use Cases Analyze Classes Identify and Analyze Packages

SYSTEM ANALYSIS — LIFE CYCLE ROLE
Phases Core Workflows Inception Elaboration Construction Transition Requirements Analysis Design Iteration Implementation Testing iter. #1 iter. #2 iter. #n-1 iter. #n — — — — — Increments

ARTIFACTS & WORKERS Architect Use-Case Engineer Component Engineer
responsible for responsible for responsible for Analysis Model Architecture Description Use-Case Realization —Analysis Analysis Class Analysis Package

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

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

5.1 SYSTEM ANALYSIS Goal: structure the use-case model into a form that is both robust and maintainable during the system’s life cycle 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

IMPORTANCE OF SYSTEM ANALYSIS
Why not go straight to design and implementation? 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)

USE-CASE MODEL ANALYSIS MODEL Uses client’s language
Uses developer’s language External view of the system Internal view of the system Use cases structure the external view Analysis classes and packages structure the internal view Used primary as acontract between client/developer to agree on system functionality Used primary by developers to understand how to design and implement the system May contains ambiguities, redundancies, inconsistencies, etc. Contrain no ambiguities, redundancies, inconsistencies, etc. Captures system functionality Outlines system realization Defines use cases Defines use-case realizations

UP — SYSTEM ANALYSIS ACTVITIES
Architectural Analysis Architect Use-Case Engineer Analyze Use Cases Analyze Classes Identify and Analyze Packages Component Engineer

5.2 UP — SYSTEM ANALYSIS ACTVITIES Architectural analysis identifies: analysis packages; obvious analysis classes; common special requirements Analyze use cases identify analysis classes distribute use case behaviour to analysis classes/objects specify interactions among analysis objects capture special requirements (nonfunctional) Analyze classes identify and maintain responsibilities (operations) of analysis classes identify and maintain the attributes/relationships of analysis classes describe any nontrivial behaviour of classes/objects Analyze packages structure packages for independence maintainability (coupling & cohesion)

USE CASE ANALYSIS : ANALYSIS CLASS
An analysis class is an abstraction of one or several classes in the final system implementation (system design usually has many more classes — up to 5 times) focuses on handling functional requirements only 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

ANALYSIS CLASS — BOUNDARY CLASS
5.3; 5.4 ANALYSIS CLASS — BOUNDARY CLASS boundary class name «boundary» boundary class name Models the interaction between the system and its actors 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!) encapsulates and isolates changes in the system’s interface

IDENTIFYING BOUNDARY CLASSES
5.4.2 IDENTIFYING BOUNDARY CLASSES 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 Specification strategy 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

ASU Course Registration System Select Courses to Teach
Boundary Classes Select Courses to Teach

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 Invoked by: Professor Flow of Events 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) The S1: Create a schedule subflow is performed. 4.2. If the REVIEW activity is selected (A3) The system retrieves and displays the professor’s teaching schedule. 4.3. If the MODIFY activity is selected (A3) The S2: Modify a schedule subflow is performed. 5. The use case ends.

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

ASU —BOUNDARY CLASSES: PROFESSOR ACTOR
Select courses to teach SelectCoursesUI Professor RequestEnrollmentUI Request enrollment list SelectCoursesUI Professor ProfessorUI RequestEnrollmentUI

ASU —BOUNDARY CLASSES: PROFESSOR ACTOR
CreateScheduleUI ReviewScheduleUI SelectCoursesUI RequestEnrollmentUI ProfessorUI ModifyScheduleUI

ANALYSIS CLASS — ENTITY CLASS
5.3.1; 5.4.1 ANALYSIS CLASS — ENTITY CLASS entity class name «entity» entity class name Models information that is long-lived and often persistent represents concepts such as an individual, a real-life object or a real-life event 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 to the information it represents Specification strategy Examine the use-case model to determine what domain model classes are accessed to carry out the use case.

ASU Course Registration System Select Courses to Teach
Entity Classes Select Courses to Teach

ASU — ENTITY CLASSES: SELECT COURSES TO TEACH
Examine the use case to determine what domain model classes are needed. Professor Select courses to teach Course Professor SelectCoursesUI CourseOffering ProfessorInfo

ANALYSIS CLASS — CONTROL CLASS
5.3.1; 5.4.3 ANALYSIS CLASS — CONTROL CLASS Models coordination, sequencing, transaction and control behaviour for one or more use cases control class name «control» control class name 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 encapsulates and isolates changes to control logic

ANALYSIS CLASS — CONTROL CLASS
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!

ASU Course Registration System System Analysis Control Classes Use Case: Select Courses to Teach

ASU — CONTROL CLASS: SELECT COURSES TO TEACH
Assign one control class for each actor/use case pair. Professor Select courses to teach Course Professor SelectCoursesUI SelectCoursesMgr CourseOffering How should we “connect” boundary, control and entity classes? ProfessorInfo

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

ANALYSIS CLASS INTERACTION — BEST PRACTICES
Actors can interact only with boundary classes Boundary classes can interact only with control classes and actors (initially) (Later we will see they can also interact with entity classes) boundary class Entity classes can interact only with control classes (initially) (Later we will see they can also interact with boundary classes) entity class Control classes can interact with boundary, entity and other control classes These practices result in a well structured and maintainable system.

COMMUNICATION DIAGRAM
Shows the objects involved and the messages that flow between the objects to carry out a use-case scenario message name course form: CourseForm 1: set course info receiver 2: process sender sender 3: change course sequence number John: Registrar receiver : CurriculumMgr guard condition sender message [course exists] 3.1*: change course anonymous object receiver iteration marker COMP 211: Course named objects

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 sent from sender to receiver ® indicated by an arrow 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)]

COMMUNICATION DIAGRAMS (cont’d)
keep them simple –> goal is clarity of understanding 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 special designations for objects : Line {new} {new}  created during execution : Line {destroyed} {destroyed}  destroyed during execution : Line {transient} {transient}  created and destroyed during execution

ASU Course Registration System System Analysis Communication Diagram Use Case: Select Courses to Teach

ASU COMMUNICATION DIAGRAM: 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).

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

ASU: DOMAIN MODEL (REVIISION 1)

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.

ASU: DOMAIN MODEL (REVIISION 2)

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.

ASU FLOW OF ANALYSIS: SELECT COURSES TO TEACH
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).

SEQUENCE DIAGRAMS relative time message activation time
2.4.3; 5.4.4 SEQUENCE DIAGRAMS Shows the interactions among objects arranged in time sequence : Registrar : CourseFormUI : CurriculumMgr : Course set course info relative time process guard condition change course [course exists] change course message * iteration marker activation time return (optional) lifeline

SEQUENCE DIAGRAMS (cont’d)
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

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)

ASU Course Registration System System Analysis Sequence Diagram Use Case: Select Courses to Teach

ASU — SEQUENCE DIAGRAM Select Courses to Teach (Create a schedule)
: Professor : SelectCoursesUI : SelectCoursesMgr : Course : CourseOffering : ProfessorInfo : Section : ASUMainUI Choose option Select courses to teach Start scheduling process Direct translation of collaboration diagram Display Select courses to teach window Enter semester and year Display Create schedule form Retrieve choices of courses to teach Get available courses Get available offerings Get available sections Add courses to teach Confirm creation Add courses to teach Update teaching schedule Update teaching schedule

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 professor􀀁s 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.

ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH
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).

ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH
7.3. For each section of the course offering The SelectCoursesToTeachMgr role retrieves the Section role (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 professor􀀁s 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).

MORE ON SEQUENCE DIAGRAMS
object creation : Actor ob3: C3 ob4: C4 op ob1: C1 [x>0]foo ob2: C2 [x0]bar doit branching doit self delegation X more object destruction X

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. : Actor new aTransaction new aTransaction Coordinator new afirst Transaction Checker new asecond Transaction Checker fail killCheckers X kill X beInvalid X 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

ISSUES TO CONSIDER IN MESSAGE DEFINITION
message naming similar behavior  same name should reflect distribution of responsibilities between classes 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 handled the same as ordinary message handling

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.

COMMUNICATION VS SEQUENCE DIAGRAMS
Why are there two different diagrams? 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)

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. Has * RentalHistory HasReview 1 Provides Reserves 0..5 0..1 Buys quantity Review Customer Member RentalCopy MovieVideo CurrentRental

SEQUENCE DIAGRAM EXAMPLE (cont’d)
Reserve video (staff scenario) This use case allows a staff to reserve up to 5 videos at a time for a member. Actors Invoked by Staff 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.

SEQUENCE DIAGRAM EXAMPLE:SOLUTION
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).

(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)

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.

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.

SEQUENCE DIAGRAM :COMMON ERRORS
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 represent physical actions. 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.

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

ASU — USE CASE PARTITIONING EXAMPLE
Use-Case Model Select courses to teach «trace» Analysis Model Select courses to teach participant SelectCoursesUI SelectCoursesMgr Course CourseOffering Section ProfessorInfo

ASU Course Registration System System Analysis Analysis Class Diagram

ASU CLASS DIAGRAM—ANALYSIS:

ANALYZE CLASSES Identify responsibilities of each analysis class
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 links/messages in the collaboration/sequence diagrams 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.

CRC CARDS — CLASSES, RESPONSIBILITIES, COLLABORATIONS
Class name Responsibilities Collaborators Tasks that the class is required to carry out (will become one or more operations on the class) The classes that are used to carry out the tasks (helper classes) 3”x5” card helps us to “think object” too many responsibilities ® low cohesion too many collaborators ® high coupling At most 3-5 responsibilities for each class.

ASU Course Registration System System Analysis Analysis Class Diagram CRC Card: Select Courses to Teach

ASU — CLASS ANALYSIS Select Courses to Teach For each analysis class, this information can be determined by examining all of the communication/sequence diagrams for the use case in which the class plays a role.

STATE MACHINE DIAGRAM It is a directed graph that shows:
2.4.4; 5.4.7 STATE MACHINE DIAGRAM 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

A STATE MACHINE DIAGRAM — BANKACCOUNT CLASS
Setup InCredit Closed Overdrawn [balance>0] / set state=active after(5 years) [balance<0] closeAccount / set state=inactive Frozen [balance≥0] after(3 months)/ send BankManager.accountFrozen(account#)

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

STATE MACHINE DIAGRAM — SPECIAL STATES
initial state (start state) each diagram must have one and only one initial state final state (end state) Each diagram can have multiple final states InCredit States may be named Unnamed states are referred to as anonymous states

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 message sending ® to one or more objects

STATE MACHINE DIAGRAM — EVENT
Something that happens at an instantaneous point in time Two events may be: causally related ® one has to occur before the other (sequential) unrelated ® can occur simultaneously (concurrent) 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) time event – absolute time ® when(date=07/03/2002) – elapsed time ® after(10 seconds) signal event – the receipt of an asynchronous communication from an object E v e n t y p s

STATE MACHINE DIAGRAM EXAMPLES
deposit (m)/ addMoney(m) withdraw(m) / subtractMoney(n) when(balance < overdraftLimit) / notifyManager Overdrawn [balance≥0] InCredit [balance<0] Frozen after(3 months) Call event Change event Time event

STATE MACHINE DIAGRAM : EVENT/TRANSITION MECHANICS
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

STATE MACHINE T DIAGRAM — ACTIONS & ACTIVITIES
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 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

STATE MACHINE DIAGRAM : ACTION & ACTIVITIES EXAMPLES
entry / display password exit / validate alphaKeypress / echo * help / display do / get EnteringPassword state name entry and exit actions internal transitions internal activity

ASU Course Registration System System Analysis Class Analysis State Machine Diagram: Section Class

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.

ASU — STATE MACHINE DIAGRAM
Section Class [#enrolled=40] registrationClosed [#enrolled<10] registrationClosed [#enrolled≥10] Closed Canceled addStudent / register(student) dropStudent / unregister(student) Open set #enrolled=0 registrationClosed do unregister(all) do deleteSchedule do delete(self)

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. Has * RentalHistory HasReview 1 Provides Reserves 0..5 0..1 Buys quantity Review Customer Member RentalCopy MovieVideo CurrentRental

STATE MACHINE DIAGRAM EXAMPLE
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 store􀀁s inventory and return rented videos to the store's inventory.

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)

SEQUENTIAL COMPOSITE STATECHART DIAGRAM
Transmission Neutral Forward Reverse select R select N select F

SEQUENTIAL COMPOSITE STATE MACHINE DIAGRAM
superstate Transmission select R Neutral Reverse select N select N select F substate Forward stop upshift upshift First Second Third downshift downshift

CONCURRENT COMPOSITE STATE MACHINE DIAGRAM
arises when an object can be partitioned into subsets of attributes or links, each with its own statechart diagram fail Result of Taking A Class Incomplete Passed Take Exam pass Term Project project done lab 2 done Lab 1 Lab 2 lab 1 Failed Result of Taking A Class Passed Failed Incomplete

COMPOSITE STATE MACHINE DIAGRAM : TRANSITIONS
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 COMPOSITE STATE MACHINE DIAGRAM — SYNCHRONIZATION
Example state multiple target states multiple source states Concurrent state 1 A1 A2 setup cleanup Concurrent state 2 B1 B2 synchronization bar (fork) synchronization bar (join)

CONCURRENT COMPOSITE STATECHART DIAGRAM — SYNCHRONIZATION (cont’d)
Example state Concurrent state 1 A1 A2 setup cleanup Concurrent state 2 B1 B2

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. – This is specified as: state-machine-diagram-name in state-name state-machine-diagram-name not in state-name message sending – An object can send a message to another object to cause it to change state.

CONCURRENCY AMONG STATECHART DIAGRAMS
Ignition guard references Transmission statechart diagram [Transmission in Neutral] release key Off turn key to start Starting On turn key off Transmission select R Neutral Reverse select N select N select F Forward stop upshift upshift First Second Third downshift downshift

CONCURRENCY AMONG STATECHART DIAGRAMS
VCR toggle power Off On toggle power toggle power Remote Control “power” button ^VCR.toggle power “VCR” Controlling TV Controlling VCR “power” button ^Television.toggle power “TV” toggle power Television toggle power Off On toggle power

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

2.4.5 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

ACTIVITY DIAGRAMS VS INTERACTION DIAGRAMS
look at operations that are passed among objects shows flow of control from activity to activity represents states of the executing computation interaction diagram look at the objects that pass messages shows flow of control from object to object

EXAMPLE ORDER PROCESSING :USE CASE
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.

EXAMPLE ORDER PROCESSING : DOMAIN MODEL
Places 1 * Order dateReceived isPrepaid number price dispatch() close() Customer name address creditRating() OrderLine quantity isSatisfied Item description stockQuantity ConsistsOf IsFor

EXAMPLE ORDER PROCESSING :ACTIVITY DIAGRAM
Receive Order Reorder Item Dispatch Check Line Assign to Authorize Payment Cancel for each line item on order * [in stock] [need to reorder] [stock assigned to all line items and payment authorized] [succeeded] [failed] <<iterative>>

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 represents states of the executing computation/workflow not an object 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

ACTIVITY DIAGRAM :CONTROW FLOW
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.

ACTIVITY DIAGRAM : CONTROW NODE
A control node coordinates control flflows. initial node – indicates where execution starts (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

ACTIVITY DIAGRAM : CONTROW NODE
fork – indicates a point at which independent, concurrent 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.

ACTIVITY DIAGRAM: EXPANSION REGION
An expansion region marks an area where actions 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.

ACTIVITY DIAGRAM: SPECIAL ACTION NODE
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.

EXAMPLE — REPLENISH SUPPLY ACTIVITY DIAGRAM
Receive Supply Choose Outstanding Order Items list of order items Assign Goods to Order [payment approved] Dispatch Order Add Remainder to Stock

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

ACTIVITY DIAGRAM : SIGNAL EXAMPLE

ACTIVITY DIAGRAM : EXCEPTION
Exception processing consists of two phases: 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.

ACTIVITY DIAGRAM : EXCEPTION EXAMPLE—URL VIEWER

EXAMPLE — ORDER PROCESSING/REPLENISH SUPPLY
Receive Order Reorder Item Dispatch Check Line Assign Authorize Payment Cancel for each line item on order * [in stock] [need to reorder] [stock assigned to all line items and payment authorized] [succeeded] [failed] Supply Choose Outstanding Order Items Goods to for each chosen order item [all outstanding order items filled] Add Remainder to Stock

ACTIVITY DIAGRAM : PARTION (SWIMLANES)
A partition show who/what is responsible for an activity The responsible entity may be is a: use cases classes components organizational units in an organization 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

SWIMLANES Warehouse Processing Finance Receive Order Reorder Item
Dispatch Check Line Assign to for each line item on order * [in stock] [need to reorder] [stock assigned to all line items and payment authorized] Authorize Payment Cancel [succeeded] [failed] Supply Choose Outstanding Order Items Assign Goods to for each chosen order item [all outstanding order items filled] Add Remainder to Stock Processing Finance Warehouse SWIMLANES

ACTIVITY DIAGRAM : PARTION EXAMPLE

ASU Course Registration System SYSTEM ANALYSIS CLASS ANALYSIS Activity Diagrams

ASU ACTIVITY Manage section workflow Create section [cancel] Assign
grades instructor web page Register for section Cancel [offer]

ASU ACTIVITY DIAGRAM Manage section workflow Registrar Professor
Register for section Create section [cancel] Assign grades instructor web page Cancel [offer] Registrar Professor Student

ASU — ACTIVITY DIAGRAM 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.

ASU ACTIVITY DIAGRAM Register for a course procedure Check enrollment
[closed] Abort registration prerequisites exclusions permission Register [has exclusions] [does not have prerequisites] permission] [open] exclusions] [has prerequisites] [has permission] Register for a course procedure

WHEN TO USE ACTIVITY DIAGRAMS
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

Goal: localize changes to the system
2.4.6 PACKAGE package name A mechanism used to group analysis classes for ease of use, maintainability, and reusability can contain: analysis classes use-case realizations other analysis packages (nested packages ® 2-3 levels sufficient!) 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 Goal: localize changes to the system

Consider navigability
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 package B A Consider navigability for shared classes, we can: place it in its own package place it just outside all packages and let other packages depend on it package A shared class B

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 «use» «import» «access» analysis model design «trace»

PACKAGE NAMESPACE a package defines an encapsulated name space
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 «import» A

ensures that a package has a small, simple interface
PACKAGE VISIBILITY elements inside a package may be given a visibility: + 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

PACKAGE DESIGN — COHESION & COUPLING
Goal: independent and loosely coupled but highly cohesive 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 There is a trade-off between cohesion and coupling (7 ± 2 heuristic)

COHESION cohesion spectrum coincidental - every 60 lines of code
logical temporal procedural communicational sequential functional “scatter-brained” “single-minded” High Low cohesion spectrum coincidental - every 60 lines of code 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

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

COUPLING coupling spectrum no direct - packages are not related
data stamp control external common content High Low coupling spectrum no direct - packages are not related 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

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

PACKAGES — ARCHITECTURAL ANALYSIS
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

ASU — PACKAGES & DEPENDENCIES: DESIGN 1
Layer Package Application-specific layer Information Maintenance Course Registration Registration Data Application-general layer

ASU — PACKAGES: DESIGN II
People Maintenance Register for courses Student Billing System Professor Request enrollment list Select courses to teach Registrar Maintain course information Prepare course catalogue Maintain student information Maintain professor information Prepare billing information Time Course Maintenance Course Registration

Partition Information Maintenance functionality into Course Maintenance and People Maintenance Application-specific layer Course Maintenance Course Registration People Maintenance Application-general layer Registration Database

Interfaces Separate UI from other functionality Application-specific layer Course Maintenance Course Registration People Maintenance Application-general layer Registration Database

SYSTEM ANALYSIS : RETROSPECTIVE
Use-case analysis 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 Assigns responsibilities to and identifies collaborators of classes. state machine diagrams – specify object behaviour (as needed) activity diagrams – specify the methods of an operation Package analysis Organizes analysis classes into cohesive, loosely coupled units.

SUMMARY — SYSTEM ANALYSIS
Analysis model contains: analysis packages, service packages and their dependencies 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 Localizes changes in use cases architectural view of the analysis model Localizes changes to architecture These are all documented in the System Analysis Specification (SAS)

310313 SOFTWARE ENGINEERING SYSTEM ANALYSIS.

Similar presentations

Presentation on theme: "310313 SOFTWARE ENGINEERING SYSTEM ANALYSIS."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

310313 SOFTWARE ENGINEERING SYSTEM ANALYSIS.

Similar presentations

Presentation on theme: "310313 SOFTWARE ENGINEERING SYSTEM ANALYSIS."— Presentation transcript:

Similar presentations

About project

Feedback