1 / 42

UML’s StateChart

UML’s StateChart. FSM, EFSM in UML Concurrent states Tool support. Example. Consider the following requirements describing the life cycle of a bank account entity.

alan-flynn
Télécharger la présentation

UML’s StateChart

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. UML’s StateChart • FSM, EFSM in UML • Concurrent states • Tool support

  2. Example • Consider the following requirements describing the life cycle of a bank account entity. • A bank account is first created by a bank manager. The customer owning the account has to activate the account within one month. Otherwise, this account will be automatically cancelled. Once activated, the customer can use the account to perform bank transactions. The account becomes blocked for security reasons or if it is dormant for more than six months. In either case, the customer is asked to contact the bank. After being blocked for two weeks, if the customer does not contact the bank, the account will be cancelled. The customer may cancel the account at any time while it is active. • States: created, active, blocked and cancelled.

  3. Concurrent states in StateCharts • Concurrent activities when superstate state ‘created’ is reached

  4. UML’s Activity diagram • Describe dynamic behavior – sequential and concurrent flows of activities • May involve activities spanning more than one use case • Action states, activity states and transitions between them, and swimlanes • Includes symbols from Petri Nets and Flowcharts

  5. Example • Given the following English description of the flow of activities within a company that receives orders through the internet. • “Once the order is received by the Customer Service department, the customer’s credit is checked. If the customer has a bad credit rating, the order is rejected and closed. Otherwise, an invoice is prepared and sent to the Finance department for follow up, and at the same time the order is sent to the Order Fulfillment department. The Finance department processes the payment once received and informs the Customer Service department. Also, the Order Fulfillment department checks if the ordered items are available. If available, the order is delivered to the customer, otherwise it is back ordered. In either case, the Customer Service department is informed.

  6. Process modeling: Data flow diagram (DFD) • Process transforming input data and control into output data and control • Bubble representing a process • Arcs carrying flow of data and control in and out of a process • Data store as source and sink of data • External entities as source and sink of data

  7. Data flow diagram (DFD)

  8. Consistency of process refinement • Process 2. is refined into 4 subprocesses 2.1 to 2.4

  9. Example • Consider the following informal requirements. • ‘An online book ordering system accepts orders from buyers which could be either human users or software agents. A book order is normally made after the buyer browses a books catalog. The system checks the availability of the ordered items in the store inventory and the status of the buyer in the customer file. If all items are available and the customer has a good record, the buyer is asked to provide credit card payment and shipping information. The payment information is then passed to a payment server to verify their validity. If the payment information is valid, an online bill and payment confirmation is sent to the buyer. Otherwise, the buyer is informed of the rejection of the payment information, and consequently the order. In the meantime, the inventory file, the customer information file and the orders file are updated. In addition, customer information including name and shipping address are used to deliver the ordered items to the buyer”.

  10. Context level diagram

  11. First refinement

  12. Refinement of validate order process

  13. Structured English, Decision Table and Decision Tree • To describe a process • Typically used for a stateless (no internal states, no memory of previous inputs) process • Pseudocode, structured english

  14. Decision table • Rows in the table are of two types: condition rows and action rows. • A column represents a combination of condition outcomes and the corresponding actions to take. • also referred to as a rule. • A complete decision table specifies one rule for each combination of the condition outcomes. • For example, if we have three independent binary conditions, the number of combinations or rules must be 23 = 8. • A decision table contains redundancy, it there exists two columns that are equivalent. • A decision table is ambiguous or contradictory if for the same combination of condition outcomes, the specified actions are different.

  15. Data modeling • Chen’s entity relationship diagram (ERD) • Entities representing objects to be saved in permanent stores • Attributes for each entity • Relationships linking entities (binary, ternary, .. Relationships) • Cardinality of the relationship: 1 to 1, 1 to many, and many to many

  16. Data dictionary • Explaining the data items in a DFD or ERD • For example in level 0 (first refinement) DFD of Figure 4.21: • reply = Msg1 or Msg2 or Msg3 in the data dictionary. • Msg1 = ‘Unable to accept your order at this moment’ • Msg2 = ‘Unavailable items at this moment’ • Msg3 = ‘Thank you for your order – Please proceed with payment’.

  17. Formal specification techniques • Mostly implementation oriented or very abstract and theoretical (not desirable!) • Desirable properties of specification techniques • General, generic, expressive • Formal with well defined semantics • Readable, modular • Abstract to a certain degree • Traceable, testable • Executable

  18. Object oriented analysis (OOA) • Based on the identification of problem-domain objects, their attributes and operations • Identification of relationships among objects • Object states and transitions among them • Description of the interactions among objects • Textual analysis of requirements: nouns and verbs

  19. What can be an problem domain Object? • Entities that have more than one attribute • Entities that need to be retained in permanent storage for future use • External entities that produce information to be used or consumed by the system, or that consume information generated or produced by the system • Events or actions that occur during the system’s operations • Roles played by people interacting with the system • Organizational units and places that are important in the problem domain such as flight crew team or airport • Logical items such as flight reports and documents • Composite physical items such as an airplane or a personal computer

  20. Three types of solution domain objects • Entity objects: to remain in permanent store for future use and reference • Interface objects: forms, GUI components that are used but are not saved (transient objects) • Control objects: encoding the business procedure or control flow (one per use case?)

  21. Example • Let us analyze the following English text providing a partial description of the requirements for a Proposal Evaluation System (PES). “PES allows different types of users to perform their functions. The three types of users are Evaluators, Administrators and Proposal Submitters. Users must first logon successfully to the system to be able to work. Submitters will submit their proposals. An Administrator will perform a basic evaluation of the proposal before assigning it to an Evaluator. The basic evaluation checks whether the Submitter has already submitted another pending proposal. If so the submission fails the check. In addition, the Submitter cannot have more than two accepted proposals to pass the basic check. If the proposal does not pass the basic check, the Submitter is informed and the refusal is logged in history.

  22. Example • An Administrator sends an email to the Evaluator once she/he is assigned to a proposal. The Evaluator will evaluate the proposal and will send his/her evaluation to the Administrator either by email or by filling a form on the internet. The Administrator will inform the Submitter of the result of the evaluation. At this point the proposal evaluation process is considered done”.

  23. Object relationships:inheritance (generalization/specialization, is_a) Composition relationship (includes, made of)

  24. Associations and roles

  25. Dynamic object behavior • Object interactions – interaction diagrams • Sequence diagram • Communication diagram • 1 to 1 mapping from sequence to communication diagram

  26. Sequence diagram

  27. Communication diagram

  28. Specification validation • Completeness • Review meetings, walkthroughs, checklists • Check NFRs • All external interfaces are identified • Correctness • Absence of deadlocks, livelocks, liveloops • Checking needed invariants • Optimal interactions • Check all relationships, cardinalities, associations,… • Execute model or review in meetings

  29. Section 3 of the SRS

  30. External interfaces specification • Input to the system • Using forms, dialogs • Records from saved files (from data model) • Format of inputs from other external systems • Output from the system • Confirmation, help, error, and warning messages • Music files • Reports to be saved or printed • Format of output to other external systems

  31. Example • Given the following English specification for a Web-based order processing system for a computer store. “A new user can connect to the company’s web page and create a new customer profile by providing personal information. This information will be validated and saved in a customer information file at the company’ s server. The user is then provided with a user id and password via an email sent by the system. Using the provided password, the user can then logon to the system and place an order. The user can also delete or update an order within a certain time after placing the order. In all cases, the system will verify the transaction and act accordingly. If the transaction is not allowed (e.g., deleting after the deadline) the user is informed.

  32. Example • Before accepting the transaction, the system checks the customer information file for credit check and the inventory file for availability. If the ordered item is not available, the system will ask the user whether to keep the order in a back order file, otherwise the order is discarded. If the product is available, the inventory and customer information files are updated accordingly. The ordered product is delivered along with a bill, and the accounting file is updated. Once the payment is received, the accounting file and the customer information files are updated accordingly. From time to time, the system administrator send emails to customers informing them about special deals …”. • Draw Data Flow Diagrams at all levels. Produce an object-oriented analysis model.

More Related