Topic 4: Object-Oriented Approach to Requirements Engineering. Software Engineering. Faculty of Computing Universiti Teknologi Malaysia

Transcription

1 Topic 4: Object-Oriented Approach to Requirements Engineering Software Engineering Faculty of Computing Universiti Teknologi Malaysia

2 Software Engineering 2 Topic Outline Part I: Requirements Document Software Requirements Specification (SRS) Part II: Requirements Modeling Concept Use Case Modeling and Specification System Sequence Diagram (SSD) Activity Diagram Domain Modeling Statechart Diagram

3 Software Engineering 3 Requirements Document Software Requirements Specification (SRS) PART I

4 Software Engineering 4 Objective To understand how requirements may be organized in a software requirements document To adopt a standard in producing a requirements document

5 Software Engineering 5 The Software Requirements Document Software requirements document is an official statement of what is required for the reference of software developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set WHAT the system should do rather than HOW it should do it.

6 Software Engineering 6 User and System Requirements Recall

7 Users of a Requirements Document Software Engineering 7

8 Software Engineering 8 Requirements Document Variability Information in requirements document depends on type of system and the approach used in its development. Systems developed incrementally will, typically, have less detail in the requirements document. Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large software projects.

9 IEEE Std Software Engineering 9

10 Software Engineering 10 SRS Outline of IEEE Std See page 11 of IEEE Std

11 Software Engineering 11 Example of Template for the Front Part of SRS Document

12 Section 1: Introduction Software Engineering 12

13 Software Engineering 13 Section 2: Overall Description, Sub-Section 2.1

14 Sub-sections to Software Engineering 14

15 Sub-sections 2.2 & 2.3 Software Engineering 15

16 Sub-sections 2.4 to 2.6 Software Engineering 16

17 Section 3: Specific Requirements Software Engineering 17

18 Software Engineering 18 A.5 Template of SRS Section 3: Organized by Feature Section to Section provide the details of what described in to Consider to organize Section 3.2 by the modules i.e. map each feature with each module and map respective use case in the module with its functional requirement. For each functional requirement, indicate its details using use case description. Include sequence diagram (of system level also known as system sequence diagram) and activity diagram for each use case i.e. functional requirement.

19 Software Engineering 19 Key Points The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers or users and software developers can use it.

20 Software Engineering 20 Requirements Modeling Concept Reference: Satzinger et al. (2011) PART II

21 Software Engineering 21 Requirements Models: Traditional Approach vs. Object-Oriented Approach

22 Software Engineering 22 Overview of Models Used in Requirements and Design Logical models specify processes Physical models are based on logical models Implement some component of the system Included within the design discipline UML diagrams are used in system development Additional models also used

23 UML Diagrams used for Modeling Software Engineering 23

24 Software Engineering 24 Additional Models used for Requirements and Design Disciplines

25 Software Engineering 25 Case Study 1 ROCKY MOUNTAIN OUTFITTERS (RMO)

26 Software Engineering 26 Rocky Mountain Outfitters and Its Strategic Information Systems Plan RMO serves role of case study for text Business: manufacture and distribute sports clothing Project: develop new customer support system Initial activities Understand the nature of the business Investigate current information system Define basic objectives of customer support system Develop the information systems strategic plan

27 Early RMO Catalog Cover (Spring 1978) Software Engineering 27

28 Software Engineering 28 Introducing Rocky Mountain Outfitters (RMO) RMO founded by John and Liz Blankens in 1978 Staff consists of 600 people Annual sales have risen to nearly $100 million Mail-order operation contributes $60 million In-store retail sales account for $7.5 million Phone-order operation accounts for $30 million

29 Current RMO Catalog (Spring 2006) Software Engineering 29

30 Software Engineering 30 RMO Strategic Issues Founders commit to business expansion in 2002 Growth channel: business-to-consumer (B2C) e- commerce Two key strategic thrusts support five year plan: Supply chain management (SCM) Customer relationship management (CRM) Object-oriented technology and techniques shape system development projects

31 Software Engineering 31 RMO s Organizational Structure and Locations John and Liz Blankens are chief executives 113 workers employed in Park City, Utah Two retail store locations: Park City and Denver Manufacturing facilities in Salt Lake City and Portland, Oregon

32 Rocky Mountain Outfitters Organizational Structure Software Engineering 32

33 Software Engineering 33 RMO s Organizational Structure and Locations (continued) Three distribution/warehouse facilities: Salt Lake City, Albuquerque, and Portland Mail-order processing in Provo, Utah Phone-sales center in Salt Lake City

34 Rocky Mountain Outfitter s Locations Software Engineering 34

35 Software Engineering 35 The RMO Information Systems Department 50 employees in information systems department Mac Preston: chief information officer (CIO) Information system organization System support: telecommunications, database administration, operations, and user support System development team: four project managers, six systems analysts, ten programmer analysts, and support staff

36 Software Engineering 36 RMO Information Systems Department Staffing

37 Software Engineering 37 Existing RMO Systems Data center in Park City supports (8) systems: Merchandising/Distribution Mail Order Phone Order Retail Store Systems Office Systems Human Resources Accounting/Finance RMO Informational Web site

38 Software Engineering 38 The Information Systems Strategic Plan SCM and CRM provide vision for the plan Two chief components Technology Architecture Plan: emphasize distributed computing Application Architecture Plan: seamlessly integrate replacements, upgrades and new packages Timetable reflects implementation schedule

39 The Timetable for RMO s Application Architecture Plan Software Engineering 39

40 Software Engineering 40 The Customer Support System Development project: customer support system (CSS) RMO core competency: cultivating customer loyalty Application architecture plan specifies CSS objectives Includes functions associated with providing products Supports customer relationship management strategy Offers multiple sales channels: telephone, mail, retail, and Internet System details worked out in requirements analysis

41 USE CASE AND DOMAIN MODEL Software Engineering 41

42 Software Engineering 42 Objectives To define requirements using use cases and problem domain classes To identify and analyze events and resulting use cases, for use case diagram To identify and analyze domain classes for domain model class diagram To produce detail requirements using system sequence diagram, activity diagram and statechart diagram

43 Software Engineering 43 Ways of Writing a System Requirements Specification Recall Notation Natural language Structured natural language Design description language Graphical notations Mathematical specifications Description The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement. This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. These notations are based on mathematical concepts such as finitestate machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract.

44 Software Engineering 44 Events and Use Cases Use case Activity the system carries out Entry point into the modeling process Event decomposition: help identify use cases Elementary business processes (EBPs) Basic unit of analysis Initiated by event occurring at specific time and place Discrete system response that adds business value

45 Identify Use Cases: User vs. Goal Software Engineering 45

46 Software Engineering 46 Types of Events External Events Occur outside the system Usually caused by external agent Temporal Events Occurs when system reaches a point (deadline) in time State Events Asynchronous events responding to system trigger

47 Software Engineering 47 Identifying Events Distinguish events from prior conditions Can the transaction complete without interruption? Is the system waiting for next transaction? Trace sequence of events initiated by external agent such as those in activity diagram Isolate events that actually touch the system

48 Software Engineering 48 Events in the Rocky Mountain Outfitters Case Developing list of external events Identify all people and organizational units that want something from the system Developing list of temporal events Identify regular reports and statements that system must produce at certain times

49 Software Engineering 49 External Events for the RMO Customer Support System

50 Software Engineering 50 Temporal Events for the RMO Customer Support System

51 Software Engineering 51 Looking at Each Event and the Resulting Use Case Enter use cases in an event table Event table includes rows and columns Each row is a record linking an event to a use case Columns represent key information RMO event table anatomizes customer support system

52 Information about each Event and the Resulting Use Case in an Event Table Software Engineering 52

53 The Complete Event Table for the RMO Customer Support System Software Engineering 53

54 Software Engineering 54 Problem Domain Classes Problem domain Set of work-related things in system component Things have data representation within system Examples: products, orders, invoices, customers OO approach to things in problem domain Objects that interact in the system Identify and understand things in problem domain Key initial steps in defining requirements

55 Software Engineering 55 Types of Things Things can be identified with methodology Separate the tangible from the intangible Include information from all types of users Ask important questions about nature of event What actions upon things should be acknowledged and recorded by the system? Example case: customer placing an order

56 Type of Things: Example Software Engineering 56

57 Software Engineering 57 Procedure for Developing an Initial List of Things List nouns that users mention when discussing system Event table as source of potential things Use cases, external agents, triggers, response Select nouns with questions concerning relevance Further research may be needed

58 Partial List of Things Based on Nouns for RMO Software Engineering 58

59 Partial List of Things Based on Nouns for RMO Software Engineering 59

60 Partial List of Things Based on Nouns for RMO Software Engineering 60

61 Software Engineering 61 Associations among Things Analyst document entity associations (relationships) Example: is placed by and works in Associations apply in two directions Customer places an order (better to use active voice) An order is placed by a customer (passive voice not encouraged to be used Multiplicity: the number of associations One to one or one to many The associations between types of things Unary (recursive), binary, n-ary

62 Software Engineering 62 Attributes of Things Specific details of things are called attributes Analyst should identify attributes of things Identifier (key): attribute uniquely identifying thing Examples: Social Security number, vehicle ID number, or product ID number Compound attribute is a set of related attributes Example: multiple names for the same customer

63 Attributes and Values Software Engineering 63

64 Software Engineering 64 Classes and Objects Domain model class diagram as UML class OOA applies domain model class diagram to things Problem domain objects have attributes Software objects encapsulate attributes and behaviors Behavior: action that the object processes itself Software objects communicate with messages Information system is a set of interacting objects

65 Software Engineering 65 Objects Encapsulate Attributes and Methods

66 Software Engineering 66 Domain Model Class Diagram Notation Class diagram key General class symbol: rectangle with three sections Sections convey name, attributes, and behaviors Methods (behaviors) not shown in domain model class diagram Lines connecting rectangles show associations Multiplicity reflected above connecting lines Domain class objects reflect business concern, policies, and constraints

67 Software Engineering 67 Class Symbol Class Name Attribute Behavior/Method/Operation Do not include this part in analysis stage only in design stage

68 Software Engineering 68 Class Symbol with Name and Attributes: Example

69 A Simple Domain Model Class Diagram Software Engineering 69

70 Software Engineering 70 Multiplicity of Associations Recall the knowledge gained from the database course and SADM

71 A University Course Enrollment Domain Model Class Diagram with a Many-to-Many Association Software Engineering 71

72 A Refined University Course Enrollment Domain Model Class Diagram with an Association Class Software Engineering 72

73 Software Engineering 73 Hierarchies in Class Diagram Notation Generalization/specialization notation Inheritance hierarchy Rank things the more general to the more special Motor vehicle class includes trucks, cars, buses Classification: means of defining classes of things Superclass: generalization of a class Subclass: specialization of a class

74 Software Engineering 74 Hierarchies in Class Diagram Notation (continued) Whole-part Hierarchy Notation The whole is equal to the sum of the parts Two types of whole-part hierarchies Aggregation: association with independent parts (collection of) Example: keyboard is part of computer system Composition: association with dependent part (composed of) Example: CRT and monitor Multiplicity applies to whole-part relationships

75 Software Engineering 75 Hierarchies in Class Diagram Notation (continued) Design Class Diagrams (in design phase) Models classes into precise software analogs Includes domain class information plus methods Triangle symbol between classes indicates inheritance Properties of attributes are shown with curly braces Class fundamentals Instances of a class (objects) manage their own data Abstract classes are not instantiated (created) Subclasses inherit attributes/behaviors from superclass

76 Software Engineering 76 A Generalization/Specialization Hierarchy for Motor Vehicles

77 Software Engineering 77 A Generalization/Specialization Hierarchy for Orders

78 Software Engineering 78 Whole-Part (Aggregation) Relationships Between a Computer and Its Parts

79 Software Engineering 79 Domain Model Class Diagram vs Design Class Diagram Include method

80 Software Engineering 80 RMO Domain Class Diagram Derives from noun list RMO domain class diagram shows attribute Models do not show methods Problem domain classes reflect high-level view of RMO use cases

81 Software Engineering 81 Rocky Mountain Outfitters Domain Model Class Diagram

82 Software Engineering 82 Use Case Diagram, Activity Diagram, System Sequence Diagram, State Charts for State Machine Diagram DETAILED REQUIREMENTS

83 Software Engineering 83 Detailed Object-Oriented (OO) Requirements Definitions System requirements captured with OO models Divide and conquer strategy toward complexity Two subsets of OO modeling approach Use case driven extending four specific models Use case diagrams, use case descriptions, activity diagrams, system sequence diagrams Object driven extending statechart diagram

84 Requirements Diagrams With UML Models Software Engineering 84

85 Software Engineering 85 Detailed OO Requirements Definitions (continued) Use case diagram: table of contents for business events System sequence diagrams (SSDs) Define and order sequence of inputs and outputs Information flows referred to as messages Class diagrams Identify real-world things Determine the structure of the programming classes Statechart diagram describes collection of object states

86 Software Engineering 86 System Processes: A Use Case/ Scenario View Define use cases into two tiers: Overview level derived from: Event table and use case diagrams Detailed level derived from combination of: Use case description Activity diagram Sequence diagram

87 Software Engineering 87 Use Cases and Actors Source Person or thing initiating the business event who may/may not touch the system Must be external to the system Actor Person or thing that touches the system Lies outside of automation boundary Identifying actors at the right level of detail Assume actors (even non-human types) have hands Use case is a goal that the actor wants to achieve

88 Software Engineering 88 The Use Case Diagram Notation for use case diagrams Simple stick figure represents an actor Actor s hands indicate direct system access Use case itself symbolized by an oval Connecting lines match actors to use cases Actors may also be other system interfaces May be represented with stick figure or rectangle

89 A Simple Use Case with an Actor Software Engineering 89

90 Software Engineering 90 Automation Boundary and Organization Expand use case diagrams with other actors and use cases Relationship line: allows each actor to interact with each use case Automation boundary Line drawn around the entire set of use cases Defines interface between actors and computer system

91 Software Engineering 91 Use Case Diagram of Order-Entry Subsystem for RMO with a System Boundary

92 Software Engineering 92 All Uses Cases Involving the Customer Actor

93 Software Engineering 93 For a large system, the modularity is organized by subsystems. However, for a medium to small size system, consider creating modules. A Use Case Diagram of the Customer Support System (by Subsystem) Note: If possible DO NOT duplicate the same actors e.g. clerk, customer, management (see arrows)

94 Software Engineering 94 «Includes» Relationships «includes» or «uses» relationship Use case calling services of common subroutine Common subroutine itself becomes additional use case Examples: Validate customer account and Look Up Item Availability Notation Relationship denoted by connecting line with arrow Direction of the arrow indicates major/minor cases

95 Software Engineering 95 An Example of Order-Entry Subsystem with <<includes>> Use Cases

96 2016 Software Engineering 96 The <<extend>> Relationships <<extend>> relationships model exceptional or seldom invoked cases The exceptional event flows are factored out of the main event flow for clarity The direction of an <<extend>> relationship is to the extended use case Use cases representing exceptional flows can extend more than one use case

97 Software Engineering 97 Developing a Use Case Diagram Two ways to identify additional use cases Divide one large use case into two Define another use case based on a common subroutine Distinguish between temporal and state events Iterative process translates business events to use cases Identify the actors and roles for each use case Extract system response to business events Data of system stabilizes after completion of the goal

98 Software Engineering 98 Use Case Detailed Descriptions Use cases have internal complexity Sequence of steps to execute business process Several variations may exist within single use case Valid variation known as scenario Example: Create new order varies from phone to Internet order Work with variety of diagrams and descriptions for each use case

99 Software Engineering 99 Use Case Detailed Descriptions (continued) Use case descriptions written at (3) levels of detail Brief description Summary statement conjoined to activity diagram Intermediate description Expands brief description with internal flow of activities Fully Developed Description Expands intermediate description for richer view

100 Brief Description of Create New Order Use Case Software Engineering 100

101 Intermediate Description of Telephone Order Scenario for Create New Order Use Case Software Engineering 101

102 Software Engineering 102 Use Case Detailed Descriptions (continued) Fully developed use case description Superset of intermediate and brief descriptions Consists of eleven compartments User, actor, stakeholder, EBP, and conditions identified Activity Diagram Description Document the workflows of business processes Document flow of activities for use case scenarios Form basis of system sequence diagrams (SSDs)

103 2016 Software Engineering 103 Use Case Description and Functional Decomposition Functional decomposition: breaking down a problem into small, isolated parts The parts work together to provide the functionality of the system Often do not make sense in isolation Use cases are NOT functional decomposition Keep the functionality together to describe a complete use of the system

104 2016 Software Engineering 104 Bad Example: Use Case with Functional Decomposition Avoid FD: -Very small use cases -Too many use cases -Use cases with no result or value -Names with low-level operation i.e. function+data Insert Card

105 2016 Software Engineering 105 Good Example: UCD Without Functional Decomposition

106 Note: 1 Use Case must have at least 1 scenario or normal flow. Software Engineering 106

107 Software Engineering compartments Fully Developed Use Case Description of Telephone Order Scenario for Create New Order

108 Software Engineering 108 Activity Diagram of Telephone Order vs. Web Order Scenario

109 Software Engineering 109 Identifying Inputs and Outputs: System Sequence Diagram System sequence diagram (SSD) Describes flow of information Identifies interaction between actors and system Message oriented

110 Software Engineering 110 SSD Notation Actor interacts with the system via input/output SSDs use object notation Box (rectangle) refers to individual object Name of the object underlined Messages sent/received by objects, not classes Lifeline Extension of object or actor for duration of the SSD Indicates sequence of the messages sent/received

111 Software Engineering 111 Sample System Sequence Diagram (SSD)

112 Software Engineering 112 SSD Notation (continued) Message syntax can take several forms Depends on send/return direction Message semantics: actions (like commands) invoked on destination object Complete message notation:*[true/false condition] return-value := message-name (parameter-list)

113 Software Engineering 113 Repeating message (a)detailed notation, (b) Alternate notation

114 Software Engineering 114 Developing a System Sequence Diagram Begin with detailed description of use case Fully developed form Activity diagrams 4-step process for turning activity diagram into SSD Identify the input messages Describe messages from external actor to system Identify/apply special conditions to input messages Identify and add the output return messages

115 Software Engineering 115 A Simplified Activity Diagram of Telephone Order Scenario

116 Software Engineering 116 Developing a System Sequence Diagram (continued) Names of messages reflect services performed Important principle for identifying data parameters Base the list on the class diagram Attributes from the classes listed as parameters Iteratively define input/output parameters around workflows Objective: discovery and understanding

117 Software Engineering 117 SSD of Simplified Telephone Order Scenario for Create New Order Use Case Parameter

118 Software Engineering 118 SSD of Web Order Scenario for Create New Order Use Case

119 Software Engineering 119 Agent Activity Actor Direction Input message Note: Observe the link between activity diagram with SSD Parameter

120 Software Engineering 120 Agent Activity Direction Decision symbol Swimlane A Simple Activity Diagram to Demonstrate a Workflow

121 Software Engineering 121 Syncronization bar An Activity Diagram Showing Concurrent Paths

122 Software Engineering Rocky Mountain Outfitters Domain Model Class Diagram Note: Parameters in SDD correspond to attributes in relevant classes

123 2016 Software Engineering 123 State Chart or State Machine Diagram In OO approaches, state chart is drawn for a single class to show the lifetime behavior of a single object. State chart is also known as state machine diagram. State: a condition during the life of an object when it satisfies some conditions, performs some actions, or waits for an event It is found by examining the attributes and links defined for the object represented as a rectangle with rounded corners Transition represents a change of the internal condition/state of an object

124 Software Engineering 124 Identifying the Object Behavior: State Chart Diagram In brief, a state in a state chart similar to status condition Spans many business events Developed for complex problem domain classes State chart/state machine diagram Composed of ovals representing status of object Arrows represent transitions

125 2016 Software Engineering 125 Transition Notation State-A Event (arguments) [condition] / effect State-B i. Event: Single event that triggers a potential change of state i.e. from State-A to State-B. ii. Guard condition: Guard is a Boolean condition (true/false). It must be true for the transition to be taken. Optional: If missing, it indicates that the transition always occurs if event occurs. iii. Effect: Behaviors that is executed during the transition. May include operation calls, the creation or destruction of another objects, or the sending of a signal to an object. Optional: if missing, it indicates nothing is done during the transaction

126 Software Engineering 126 Simple State Machine Diagram for a Printer

127 Software Engineering 127 Identifying the Object Behavior: State chart (continued) Guidelines to help identify states Check naming convention for status conditions Simple states reflect simple conditions such as On Complex states labeled with gerunds or verb phrases Example: Being shipped Active states usually not labeled with nouns Describe only states of being of the object itself Status conditions reported to management/customers Example: Shipped

128 Software Engineering 128 Nested States And Concurrency Concurrency: condition of being in more than one state at a time Two modes of representation Use synchronization bars and concurrent paths Nest low-level states inside higher-level states Higher-level states also called composite states Complex structure of sets of states and transitions Represent a higher level of abstraction

129 Software Engineering 129 Sample Composite States for Printer Object

130 Software Engineering 130 Concurrent Paths for a Printer in On state

131 Software Engineering 131 Rules for Developing State Charts 1. Select the classes that will require statecharts 2. List all the status conditions for each group 3. Specify transitions that cause object to leave the identified state 4. Sequence state-transition combinations in correct order 5. Identify concurrent paths (if any) 6. Look for additional transitions 7. Expand each transition as appropriate 8. Review and test each statechart

132 Software Engineering 132 Developing RMO State Charts Review the domain class diagram Select classes with status conditions that need to be tracked Candidates: Order, OrderItem, InventoryItem, Shipment, Customer Choose Order and OrderItem Simplicity Location in the class hierarchy

133 Software Engineering 133

134 Software Engineering 134 Developing The Order Item State Chart Identify possible status conditions of interest Ready to be shipped On back order Shipped Continue developing statechart according to eight rules

135 Software Engineering 135 States and Exit Transitions for OrderItem

136 Software Engineering 136 Partial State Machine Diagram for OrderItem

137 Software Engineering 137 Final State Machine Diagram for OrderItem

138 Software Engineering 138 Developing the Order State Chart States mirror the life cycle of an order Application of rules leads to greater complexity Concurrent states New transitions Benefits of developing a statechart for an object Captures and clarifies business rules Gain true understanding of system requirements

139 States and Exit Transitions for Order Software Engineering 139

140 Software Engineering 140 First-Cut State Machine Diagram for Order

141 Software Engineering 141 Second-Cut State Machine Diagram for Order

142 Software Engineering 142 Integrating Object-Oriented Models Primary (or source) models Use case diagram Problem domain class diagram CRUD analysis validates model completeness Construction of one model depends on another Models capturing processes of new system Use case diagram and models to lower left Models capturing information about classes Class diagrams and dependencies

143 Software Engineering 143 Relationships among OO Requirements Models

144 Software Engineering 144 Summary OOA family of models documents users needs and defines system requirements Use case detailed models (descriptive or activity) Sequence diagrams (SSDs) Domain model class diagrams Statechart diagrams

145 Software Engineering 145 Summary (continued) Use case: single system function responding to an event Actors: human users or system interfaces that initiate system response System function decomposed into workflows SSDs, domain models, statecharts emulate routines and object interaction Software engineering terms signal transition into design phase