1. B. Computer Science (SE) (Hons.)CSEB233: Fundamentals of Software EngineeringRequirements Engineering: Modeling

2. Objectives Identify guidelines of creating requirementsanalysis models Explain structured and object-oriented analysis approaches to requirements modeling Identify three classifications of modeling elements based on object-oriented approach Apply use case diagram, activity diagram, class diagram, state diagram, and sequence diagram 3. OverviewActivityActionCommunicationTask Project InceptionRequirements EngineeringReq. Elicitation Req. Analysis & Negotiation Req. Specification Req. Verification and Validation Req. ManagementRequirements Modeling Design ModelingContext Modeling Technical ModelingPlanning Modeling Construction Deployment 4. Requirements Engineering: Modeling Guidelines of Creating Requirements Analysis/Models 5. Requirements/Analysis Model A graphical representation of business processes, the problems to be solved, and the new proposed product (software) Objectives To describe software requirements To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built Bridges the gap between a softwarespecification and a software designSoftware specification Analysis Model Design Model 6. Rules of Thumb Suggested by Arlow and Neustadt: The model should focus on requirements that are visible within the problem or business domain The level of abstraction should be relatively highEach element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system Delay consideration of infrastructure and other nonfunctional models until design 7. Rules of Thumb Suggested by Arlow and Neustadt: Minimize coupling throughout the system Be sure that the analysis model provides value to all stakeholders Keep the model as simple as possible especially if extra diagrams do not provide new information 8. Requirements Modeling Principles Principle #1: The information domain of a problem must be represented and understood Principle #2: The functions that the software performs must be defined Principle #3: The behavior of the software, as a consequence of external events, must be represented 9. Requirements Modeling Principles Principle #4: The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Principle #5: The analysis of task should move from essential information toward implementation detail 10. Requirements Engineering: Modeling Structured and Object-oriented Analysis Approaches 11. What is Domain Analysis? According to Donald Firesmith: Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . [Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks . . . 12. What is Domain Analysis? An on-going SE activity that is not connected toany software project (by domain analyst) Involves: Defining the domain to be investigated Collecting a representative sample of applications in the domain Analyzing each application in the sample Developing an analysis model for the objects 13. Requirements Analysis Modeling Categorized into two main levels of details: Context (conceptual-level) modeling* High-level conceptual descriptions of a product and its environment. Must be supplemented with detailed-level models, e.g.: architectural model Usually usable to non-technical people and decisionmakers Technical (detailed-level) modeling 14. Technical Modeling Approaches Structured Analysis Considers data and the processes that transform the data as separate entities. Includes data models, data flow models and behavioral models e.g., ERD, DFD, state machine model 15. Technical Modeling Approaches Object-oriented Analysis model objects, classes, and the relationships and behavior associated with them The industry standard for OO modeling is the Unified Modeling Language (UML) specification The current available version is 2.2 (OMG, 2009). e.g., use-case diagrams, activity diagrams (swim-lane diagram), sequence diagram, class diagram, state diagram, etc. 16. Requirements Engineering: Modeling Classifications of Modeling Elements 17. Flow-oriented Modeling Represents how data objects are transformed asthey move through the system Data flow diagram (DFD) is the diagrammatic form that is used Considered by many to be an old school approach, but continues to provide a view of the system that is unique It should be used to supplement other analysis model elements 18. OO Analysis Approach Need to first understand OO concepts, whichinclude objects, classes, attributes, methods, subclass, super-class, etc. Classifications of OO modeling elements: Scenario-based to show how end-users interact with the system e.g., use-case diagram, activity diagram, swimlane diagram 19. OO Analysis Approach Class-based to specify classes and objects, attributes, operations, and associations and dependencies e.g., class diagram, class responsibility collaborator (CRC) model, collaboration diagramBehavioral to model how the system reacts to external event e.g., event-driven use-case, state diagram, sequence diagram 20. 1. Scenario-based Modeling Use Case Ivar Jacobson: [Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases) Elements: Actor a stick figure that represent roles of people, other system (database, servers, and legacy systems) or equipment that interact with use cases in the system. 21. 1. Scenario-based Modeling Use Case Use case an oval shape labeled with the use case name (inside or outside the oval) that represent a complete unit of system functionality A use case may be made up of a set of scenario Each scenario describes the steps that consist of an interaction between the actors and the system Just like DFDs, you can continue to add detail bybreaking the uses cases into more use cases 22. Use Case Example 1 Use case diagram for SafeHome System Saf eHomeAccess camera surveillance via t he Int ernetConf igure Saf eHome syst em paramet ers homeownerSet alarmcameras 23. Use Case Example 2 Airline Reservation System Airline Reservation SystemCheck In PassengerTicket ClerkAdd New ReservationCancel Reservation 24. Relationships of Use Cases Uses An arrow drawn from use case A to use case B to indicate that in the process of completing functionality A, functionality B will be performed too e.g.,, in the Airline Reservation System, the Add New Reservation use case uses Check Space Availability and Record Passenger Information use cases 25. Relationships of Use Cases Extends An arrow drawn from use case A to use case B to indicate that the use case A is a special way of doing use case B and must be done to complete use case B e.g., in the Airline Reservation System, there are two ways to assign a seat either by assigning a window seat or by assigning an aisle seat 26. Relationships of Use Cases Example 1 Airline Reservation System usesWeigh Luggage extendsusesAssign Window SeatextendsCheck In Passenger Assign Seat usesAssign Aisle SeatusesTicket ClerkAdd New ReservationCancel ReservationCheck Seat AvailabilityRecord Passenger Information 27. 1. Scenario-based Modeling Activity Diagram Supplements the use case by providing a graphicalrepresentation of the flow of interaction within a specific scenario Activity diagrams and statechart diagrams are related While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process The activity diagram shows how those activities depend on one another 28. 1. Scenario-based Modeling Activity Diagram UMLs basic symbols: SymbolPurpose To represent an activity To represent a flow To represent branching decisions To indicate all parallel activities within the system. 29. Activity Diagram Example 1 ent er password and user IDvalid passwor ds/ IDinvalid passwor ds/ IDselec t major f unc t ionprompt f or reent ryot her f unct ions m ay also be select ed input t r ies r em ainselec t surv eillanc e no input t r ies r em aint hum bnail viewsselect a specif ic cam er aselec t spec if ic c amera - t humbnailsselec t c amera ic onv iew c amera out put in labelled windowprompt f or anot her v iewexit t his f unct ionsee anot her cam er a 30. 1. Scenario-based Modeling Swimlane Diagram A variation of activity diagram Represents the flow of activities described by the usecase, and At the same time, indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle 31. Swimlane Example 1 homeownerc a m e rai n t e rf a c eent er password and user IDvalid p asswo r d s/ ID in valid p asswo r d s/ IDselect m ajor f unct ion o t h er f u n ct io n s m ay also b eprom pt f or reent ryselect ed in p u t t r iesselect surveillancer em ain n o in p u t t r ies r em aint h u m b n ail viewsselect a sp ecif ic cam er aselect specif ic cam era - t hum bnailsselect cam era icongenerat e video out put view cam era out put in labelled windowprom pt f or anot her viewexit t h is f u n ct io n see an o t h er cam er a 32. (http://edn.embarcadero.com/article/31863SwimlaneExample 2 33. 2. Class-based ModelingClass Diagram Depicts a collection of systems classes, theirattributes, and the relationships between the classes A class is an object applicable to a system You can think of an object as any person, thing, place, concept, event, and etc. Objects have attributes (information stored about and object or variables for OO programming) and methods or operations (things an object perform) 34. Class Diagram Example 1 To model a class, use a rectanglewith three sections: name of the class (top) list of attributes (middle) methods (bottom). Example: a Student class which has attributes StudentID, Firstname, Lastname, Email, and ContactNumber. Student perform operations such as RegisterCourse, DropCourse, and PrintTranscript.StudentStudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript()Name of classList of attributesList of methods 35. Class Diagram With Several Classes Need to show how they are related to each other Two basic types of relationships between classes: Associations This relationship exists when two classes are related to each other Analyze this relationship further by identifying multiplicity of the association because there is possibility that a student might register for none, one, or several courses Some potential multiplicity indicators: (see next slide) There are other types of associations such as association class, aggregation (basic and composition), reflexive associations, and realization. For further explanation, refer to OMG (2009). 36. Class Diagram With Several Classes Example:StudentStudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript()Indicator 0..1 1 0..* 1..* N 0..n 1..nMeaning Zero or one One only Zero or more One or more Only n (where n > 1) Zero to n (where n > 1) One to n (where n > 1)0..* attended byRegistered 0..*Course CourseCode CourseName CreditHours Fees 37. Class Diagram With Several Classes Inheritance/Generalisation Different classes usually share the same attributes and/or methods To avoid repeating the same attributes and/or methods, you need to take advantage of the inheritance (also known as generalisation) mechanism When class X inherits from class Y, you may say that X is the subclass of Y and Y is the superclass of X UMLs notation for inheritance is a line with upward arrowhead pointing from the subclass to the superclass 38. Class Diagram With Several Classes Example Student StudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript()Undergraduate CreditLimit0..* Registered Course attended by 0..* CourseCode CourseName CreditHours FeesPostgraduate ProjectTitle ThesisSubmitDate 39. Class Diagram: Example Models a customer order from a retail catalog (http://edn.embarcadero.com/article/31863) 40. 2. Class-basedModelingCRC CRC modeling provides a simple means foridentifying and organizing the classes that are relevant to system or product requirements (Wir, 1990) A CRC model is really a collection of standard indexcards that represent classes The cards are divided into three sections Along the top of the card you write the name of the class In the body of the card you list the class responsibilities on the left and the collaborators on the right (Ambler, 1995) 41. CRC: ExampleClass: Class: Descrip tion: Class: Descrip tion: FloorPlan Class: Descrip tion: Responsibility: Descrip tion: Responsibility: Responsibility: Responsibility:Collaborator: Collaborator: Collaborator: Collaborator:defines floor plan name/type manages floor plan positio ning scales f lo or plan for display scales f lo or plan for display incorporates w alls , doors and w indow sWallshow s position of video camerasCamera 42. 3. BehavioralModeling Make a list of the different states of a system How does the system behave? Indicate how the system makes a transition fromone state to another How does the system change state? indicate event indicate action Draw a state diagram, also known as statechartdiagram or a sequence diagram 43. The States of a System State a set of observable circumstances that characterizes the behavior of a system at a given time State transition the movement from one state to another Event an occurrence that causes the system to exhibit some predictable form of behavior Action process that occurs as a consequence of making a transition 44. State Representations In the context of behavioral modeling, twodifferent characterizations of states must be considered the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function 45. State Representations The state of a class takes on both passive andactive characteristics A passive state is simply the current status of all of an objects attributes The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing 46. State Diagram Notations: States are rounded rectangles Transitions are arrows from one state to another Events or conditions that trigger transitions are written beside the arrows The initial state (black circle) is a dummy to start the action Final states (2 circles with inner black circle) are also dummy states that terminate the action The action that occurs as a result of an event or condition is expressed in the form/action e.g., Cancel/Quit 47. State Diagram Example 1 http://edn.embarcadero.com/article/31863 48. Statechart Diagram Example 1 State Diagram for the ControlPanel Class t imer < lockedTimet imer > lockedTimelockedpassword = incorrect & numberOfTries < maxTries comparingreadingnumberOfTries > maxTrieskey hit password ent ereddo: validat ePassw ordpassword = correctselect ingact iv at ion successful 49. 3. Behavioral Modeling Sequence Diagram An interaction diagram that show how operationsare carried out - what messages are sent and when Are organized according to time Time progresses as you go down the page The objects involved in the operation are listedfrom left to right according to when they take part in the message sequence 50. Sequence Diagram Each vertical dotted line is a lifeline, representingthe time that an object exists Each arrow is a message call An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline The activation bar represents the duration ofexecution of the message The diagram has a clarifying note, which is text inside a dog-eared rectangle 51. Sequence Diagram Example 1 co nt rol panelhomeownersyst em readyAsensors sensorssyst emreadin gpassword ent ered request lookup comparing result password = correctrequest act ivat ionnum berOf Tries > m axTrieslockedAt imer > lockedTimeselect ing act ivat ion successfulact ivat ion successfulFigure 8 .2 7 Sequence diagram (part ial) f or Saf eHome securit y f unct ion 52. Sequence Diagram Example 2 A sequence diagram for making a hotel reservation http://edn.embarcadero.com/article/31863 53. Summary You have been introduced to: Guidelines of creating requirements analysis models. Two approaches to requirements modeling structured object-oriented analysisThree classifications of modeling elements based on object-oriented approach Several OO modeling elements such as use case diagram, activity diagram, class diagram, state diagram, and sequence diagram 54. THE ENDCopyright 2013 Mohd. Sharifuddin Ahmad, PhDCollege of Information Technology