PowerPoint Presentation

CSEB233: Fundamentals of Software EngineeringSoftware RequirementsPart 2Requirements Engineering Modeling1ObjectivesIdentify guidelines of creating requirements analysis modelsExplain structured and object-oriented analysis approaches to requirements modelingIdentify three classifications of modeling elements based on object-oriented approachApply use case diagram, activity diagram, class dia-gram, state diagram, and sequence diagram2OverviewActivityActionTaskCommunicationProject InceptionRequirements Engineering

Req. ElicitationReq. Analysis & NegotiationReq. SpecificationReq. Verification and ValidationReq. Management

PlanningModelingRequirements ModelingDesign ModelingContext ModelingTechnical ModelingConstructionDeployment3Requirements Engineering: ModelingGuidelines of Creating Requirements Analysis Models4Requirements/Analysis ModelA graphical representation of business processes,the problems to be solved, and the new proposed product (software)ObjectivesTo describe software requirementsTo establish a basis for the creation of a software designTo define a set of requirements that can be validated once the software is builtBridges the gap between a software specification and a software designSoftware specificationDesign ModelAnalysis Model5Rules of ThumbSuggested by Arlow and Neustadt:The model should focus on requirements that are visible within the problem or business domainThe 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 systemDelay consideration of infrastructure and other non-functional models until design6Rules of ThumbSuggested by Arlow and Neustadt:Minimize coupling throughout the systemBe sure that the analysis model provides value to all stakeholdersKeep the model as simple as possible especially if extra diagrams do not provide new information7Requirements Modeling PrinciplesPrinciple #1:The information domain of a problem must be represented and understoodPrinciple #2:The functions that the software performs must be definedPrinciple #3:The behavior of the software, as a consequence of external events, must be represented8Requirements Modeling PrinciplesPrinciple #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 detail9Requirements Engineering: ModelingStructured and Object-oriented Analysis Approaches10What 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 . . .

11What is Domain Analysis?An on-going SE activity that is not connected to any software project (by domain analyst)Involves:Defining the domain to be investigatedCollecting a representative sample of applications in the domainAnalyzing each application in the sampleDeveloping an analysis model for the objects12Requirements Analysis ModelingCategorized into two main levels of details: Context (conceptual-level) modelingHigh-level conceptual descriptions of a product and its environment. Must be supplemented with detailed-level models, e.g.: architectural modelUsually usable to non-technical people and decision-makers Technical (detailed-level) modeling13Technical Modeling ApproachesStructured AnalysisConsiders data and the processes that transform the data as separate entities.Includes data models, data flow models and behavioral modelse.g., ERD, DFD, state machine model14Technical Modeling ApproachesObject-oriented Analysismodel objects, classes, and the relationships and behavior associated with themThe 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.15Requirements Engineering: ModelingClassifications of Modeling Elements16Flow-oriented ModelingRepresents how data objects are transformed as they move through the systemData flow diagram (DFD) is the diagrammatic form that is usedConsidered by many to be an old school approach, but continues to provide a view of the system that is uniqueIt should be used to supplement other analysis model elements17OO Analysis ApproachNeed to first understand OO concepts, which include objects, classes, attributes, methods, sub-class, super-class, etc.Classifications of OO modeling elements:Scenario-basedto show how end-users interact with the system e.g., use-case diagram, activity diagram, swimlane diagram18OO Analysis ApproachClass-basedto specify classes and objects, attributes, operations, and associations and dependenciese.g., class diagram, class responsibility collaborator (CRC) model, collaboration diagramBehavioralto model how the system reacts to external event e.g., event-driven use-case, state diagram, sequence diagram

191. Scenario-based ModelingUse CaseIvar 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:Actora stick figure that represent roles of people, other system (database, servers, and legacy systems) or equipment that interact with use cases in the system. 201. Scenario-based ModelingUse CaseUse casean oval shape labeled with the use case name (inside or outside the oval) that represent a complete unit of system functionalityA use case may be made up of a set of scenarioEach scenario describes the steps that consist of an interaction between the actors and the systemJust like DFDs, you can continue to add detail by breaking the uses cases into more use cases21Use CaseExample 1Use case diagram for SafeHome System

22Use CaseExample 2Airline Reservation System

Check In PassengerAdd New ReservationCancel ReservationAirline Reservation System

23Relationships of Use CasesUses 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 tooe.g., in the Airline Reservation System, the Add New Reservation use case uses Check Space Availability and Record Passenger Information use cases24Relationships of Use CasesExtendsAn 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 Be.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 seat25Relationships of Use CasesExample 1Airline Reservation System

Check In PassengerAdd New ReservationCancel ReservationWeigh LuggageAssign Seat Check Seat AvailabilityRecord Passenger InformationAssign Window SeatAssign Aisle Seat261. Scenario-based Modeling Activity DiagramSupplements the use case by providing a graphical representation of the flow of interaction within a specific scenarioActivity diagrams and statechart diagrams are relatedWhile 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 processThe activity diagram shows how those activities depend on one another271. Scenario-based Modeling Activity DiagramUMLs basic symbols: SymbolPurposeTo represent an activityTo represent a flowTo represent branching decisionsTo indicate all parallel activities within the system. 28Activity DiagramExample 1

291. Scenario-based ModelingSwimlane DiagramA variation of activity diagramRepresents the flow of activities described by the use-case, 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 rectangle30SwimlaneExample 1

31SwimlaneExample 2(http://edn.embarcadero.com/article/31863

322. Class-based ModelingClass DiagramDepicts a collection of systems classes, their attributes, and the relationships between the classesA class is an object applicable to a systemYou 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)33Class DiagramExample 1To model a class, use a rectangle with 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.

Student

StudentIDFirstnameLastnameEmailContactNumber

RegisterCourse()DropCourse()PrintTranscript()Name of classList of attributesList of methods34Class DiagramWith Several ClassesNeed to show how they are related to each otherTwo basic types of relationships between classes:AssociationsThis relationship exists when two classes are related to each otherAnalyze this relationship further by identifying multiplicity of the association because there is possibility that a student might register for none, one, or several coursesSome 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).

35Class DiagramWith Several ClassesExample:

Registered0..*0..*attended byCourse

CourseCodeCourseNameCreditHoursFees

Student

StudentIDFirstnameLastnameEmailContactNumber

RegisterCourse()DropCourse()PrintTranscript()IndicatorMeaning0..1Zero or one1One only0..*Zero or more1..*One or moreNOnly n (where n > 1)0..nZero to n (where n > 1)1..nOne to n (where n > 1)36Class DiagramWith Several ClassesInheritance/GeneralisationDifferent classes usually share the same attributes and/or methodsTo avoid repeating the same attributes and/or methods, you need to take advantage of the inheritance (also known as generalisation) mechanismWhen class X inherits from class Y, you may say that X is the subclass of Y and Y is the superclass of XUMLs notation for inheritance is a line with upward arrowhead pointing from the subclass to the superclass37Class DiagramWith Several ClassesExampleStudentStudentIDFirstnameLastnameEmailContactNumberRegisterCourse()DropCourse()PrintTranscript()CourseCourseCodeCourseNameCreditHoursFees

PostgraduateProjectTitleThesisSubmitDateUndergraduateCreditLimitRegistered0..*0..*attended by38Class Diagram: ExampleModels a customer order from a retail catalog(http://edn.embarcadero.com/article/31863)

392. Class-based ModelingCRCCRC modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements(Wir, 1990)A CRC model is really a collection of standard index cards that represent classesThe cards are divided into three sectionsAlong 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)

40CRC: Example

413. Behavioral ModelingMakes a list of the different states of a systemHow does the system behave?Indicate how the system makes a transition from one state to anotherHow does the system change state?indicate eventindicate actionDraw a state diagram, also known as statechart diagram or a sequence diagram42The States of a SystemStatea set of observable circumstances that characterizes the behavior of a system at a given timeState transitionthe movement from one state to anotherEventan occurrence that causes the system to exhibit some predictable form of behaviorActionprocess that occurs as a consequence of making a transition43State RepresentationsIn the context of behavioral modeling, two different characterizations of states must be consideredthe state of each class as the system performs its function andthe state of the system as observed from the outside as the system performs its function44State RepresentationsThe state of a class takes on both passive and active characteristicsA passive state is simply the current status of all of an objects attributesThe active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing45State DiagramNotations:States are rounded rectanglesTransitions are arrows from one state to anotherEvents or conditions that trigger transitions are written beside the arrowsThe initial state (black circle) is a dummy to start the actionFinal states (2 circles with inner black circle) are also dummy states that terminate the actionThe action that occurs as a result of an event or condition is expressed in the form/actione.g., Cancel/Quit46State DiagramExample 1http://edn.embarcadero.com/article/31863

47Statechart DiagramExample 1State Diagram for the ControlPanel Class

483. Behavioral ModelingSequence DiagramAn interaction diagram that show how operations are carried out - what messages are sent and whenAre organized according to timeTime progresses as you go down the pageThe objects involved in the operation are listed from left to right according to when they take part in the message sequence49Sequence DiagramEach vertical dotted line is a lifeline, representing the time that an object existsEach arrow is a message callAn arrow goes from the sender to the top of the activation bar of the message on the receiver's lifelineThe activation bar represents the duration of execution of the messageThe diagram has a clarifying note, which is text inside a dog-eared rectangle50Sequence DiagramExample 1

51Sequence DiagramExample 2A sequence diagram for making a hotel reservationhttp://edn.embarcadero.com/article/31863

52SummaryYou have been introduced to:Guidelines of creating requirements analysis models.Two approaches to requirements modelingstructured object-oriented analysisThree classifications of modeling elements based on object-oriented approachSeveral OO modeling elements such as use case diagram, activity diagram, class diagram, state diagram, and sequence diagram53

THE ENDCopyright 2014College of Information Technology54Ticket Clerk

uses

uses

uses

uses

extends

extends

Ticket Clerk