CSEB233 Fundamentals of Software Engineering Module 3: Requirements Engineering (Part 2) Badariah...
-
Upload
allison-daniel -
Category
Documents
-
view
225 -
download
0
Transcript of CSEB233 Fundamentals of Software Engineering Module 3: Requirements Engineering (Part 2) Badariah...
CSEB233Fundamentals of Software
Engineering
Module 3: Requirements Engineering
(Part 2)
Badariah Solemon 2010
Objectives
1. Identify guidelines of creating requirements analysis models.
2. Explain structured and object-oriented analysis approaches to requirements modelling.
3. Identify three classifications of modelling elements based on object-oriented approach.
4. Introduce use case diagram, activity diagram, class diagram, state diagram, and sequence diagram.
Badariah Solemon 2010
Overview
Activity Action Task
Communication InceptionRequirements Engineering Req. Elicitation
Req. Analysis & NegotiationReq. SpecificationReq. Verification and ValidationReq. Management
Planning
Modeling Requirements ModelingDesign Modeling
Context ModelingTechnical Modeling
Construction
Deployment
Badariah Solemon 2010
Requirements/Analysis Model
Badariah Solemon 2010
• A graphical representations of business processes, the problems to be solved, and the new proposed product (software).
• Objectives:1. To describe software requirements.2. To establish a basis for the creation of a software design.3. To define a set of requirements that can be
validated once the software is built.
• Bridges the gap between a software specification and a software design.
Software specification
Design Model
Analysis Model
Rules of Thumb
Badariah Solemon 2010
• Suggested by Arlow and Neustadt in Pressman (2009):– The model should focus on requirements that are visible within the
problem or business domain. The level of abstraction should be relatively high.
– Each 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 non-functional models until design.
– 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
Requirements Modeling Principles
Badariah Solemon 2010
• 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.
• 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 task should move from essential information toward implementation detail.
*Recap from chapter 4
Domain Analysis
Badariah Solemon 2010
• According to Donald Firesmith in Pressman (2009):“ 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 . . .”
What is Domain Analysis?
Badariah Solemon 2010
• An on-going SE activity that is not connected to any software project (by domain analyst)
• Involves:1. Defining the domain to be investigated.2. Collecting a representative sample of
applications in the domain.3. Analyzing each application in the sample.4. Developing an analysis model for the objects.
Requirements Analysis Modeling
• Categorized into two main levels of details: 1. 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 decision-makers
2. Technical (detailed-level) modeling
* Module 4
Badariah Solemon 2010
Approaches for Technical Modeling1. 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
2. Object-oriented Analysis– model objects, classes, and the relationships and
behavior associated with them.– The industry standard for the OO modeling is known as
Unified Modelling Language (UML) specification and 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, and etc.
* Relate with generic modeling elements in Part 1.Badariah Solemon 2010
Flow-oriented Modeling
Badariah Solemon 2010
• According to Pressman (2009):– Represents how data objects are transformed as
they 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
OO Analysis Approach
• Need to first understand OO concepts, which include objects, classes, attributes, methods, sub-class, super-class, and etc.
• Classifications of OO modeling elements (Pressman, 2005):
1. Scenario-based• to show how end-users interact with the system • e.g.: use-case diagram, activity diagram, swim-lane
diagram
Badariah Solemon 2010
OO Analysis Approach (cont’d)
2. Class-based• to specify classes and objects, attributes, operations,
and associations and dependencies. • e.g.: class diagram, class responsibility collaborator
(CRC) model, collaboration diagram.
3. Behavioral• to model how the system reacts to external event .• e.g.: event-driven use case, state diagram, sequence
diagram.
Badariah Solemon 2010
Scenario-based Modelling: 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:1. 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.
Badariah Solemon 2010
Scenario-based Modeling: Use Case (cnt’d)2. 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 steps that consist of an interaction between the actors and the system.
• Just like DFDs, you can continue to add detail by breaking the uses cases into more use cases.
Badariah Solemon 2010
Use Case: Example #1
Badariah Solemon 2010
University Library System
Use Case: Example #2
Badariah Solemon 2010
• Airline Reservation System
Ticket Clerk
Check In Passenger
Add New Reservation
Cancel Reservation
Airline Reservation System
Relationships of Use Cases
Badariah Solemon 2010
1. 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.
– For example, in the Airline Reservation System, the ‘Add New Reservation’ use case uses ‘Check Space Availability’ and ‘Record Passenger Information’ use cases.
2. 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.
– For example, 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.
Relationships of Use Cases: Example #1
Badariah Solemon 2010
Airline Reservation System
«uses»
«uses»
«uses»
«uses»
«extends»
«extends»
Ticket Clerk
Check In Passenger
Add New Reservation
Cancel Reservation
Weigh Luggage
Assign Seat
Check Seat Availability
Record Passenger Information
Assign Window Seat
Assign Aisle Seat
B
A
B
A
A
A B
B
Scenario-based Modeling: Activity Diagram• Supplements the use case by providing a graphical
representation 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 the how those activities depend on one another.
• UML’s basic symbols:
Badariah Solemon 2010
Symbol Purpose
To represent an activity
To represent a flow
To represent branching decisions
To indicate all parallel activities within the system.
Activity Diagram: Example #1
Badariah Solemon 2010
• Pressman (2009), pp 162
enter password and user ID
select major function
valid passwords/ ID
prompt for reentry
invalid passwords/ ID
input tries remain
no inputtries remain
select surveillance
other functions may also be
selected
thumbnail views select a specif ic camera
select camera icon
prompt for another view
select specific camera - thumbnails
exit this f unction see another camera
view camera output in labelled window
Scenario-based Modeling: Swimlane Diagram• A variation of activity diagram.• To represent 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 rectangle.
Badariah Solemon 2010
Swimlane: Example #1
• Pressman (2009), pp 163
Badariah Solemon 2010
enter password and user ID
select major function
valid passwords/ ID
prompt for reentry
invalidpasswords/ ID
input tries
remain
no input
tries remain
select surveillance
other f unct ions may also be
selected
thumbnail views select a specif ic camera
select camera icon
generate video output
select specific camera - thumbnails
exit th isfunct ion
see
anothercamera
homeowner c amera int erf ac e
prompt foranother view
view camera output in labelled window
Swimlane: Example #2
(htt
p://
edn.
emba
rcad
ero.
com
/arti
cle/
3186
3
Badariah Solemon 2010
Class-based Modeling: Class Diagram1. Depicts a collection of system’s classes, their
attributes, and the relationships between the classes.
2. 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).
Badariah Solemon 2010
Class Diagram: Example #1
Badariah Solemon 2010
• To model a class, use a rectangle with three sections: 1. name of the class (top)2. list of attributes (middle)3. 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 class
List of attributes
List of methods
Class Diagram: with Several Classes
Badariah Solemon 2010
• Need to show how they are related to each other. • Two basic types of relationships between classes:
1. Associations• This relationship exists when two classes are related to each
other in any way• You may need to analyse further this relationship by identifying
multiplicity of the association because there is possibility that a students might register for none, one, or several courses.
• Among the potential multiplicity indicators: (next page)• There exist other types of associations such as association class,
aggregation (basic and composition), reflexive associations, and realisation. For further explanation, refer to OMG (2009).
Class Diagram: with Several Classes (cnt’d)
Badariah Solemon 2010
• Example:Registered
0..*0..*attended by
Course
CourseCodeCourseNameCreditHoursFees
Student
StudentIDFirstnameLastnameEmailContactNumber
RegisterCourse()DropCourse()PrintTranscript()
Indicator Meaning0..1 Zero or one1 One only0..* Zero or more1..* One or moreN Only n (where n > 1)0..n Zero to n (where n > 1)
1..n One to n (where n > 1)
Class Diagram: with Several Classes (cnt’d)
Badariah Solemon 2010
2. 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.
• UML’s notation for inheritance is a line with upward arrowhead pointing from the subclass to the superclass.
Class Diagram: with Several Classes (cnt’d)
Badariah Solemon 2010
• Example:
* ATM Case Study
PostgraduateProjectTitleThesisSubmitDate
PostgraduateProjectTitleThesisSubmitDate
PostgraduateProjectTitleThesisSubmitDate
Course
CourseCodeCourseNameCreditHoursFees
Student
StudentIDFirstnameLastnameEmailContactNumber
RegisterCourse()DropCourse()PrintTranscript()
Postgraduate ProjectTitleThesisSubmitDate
Undergraduate CreditLimit
Registered
0..*
0..*attended by
Class Diagram: Example
Badariah Solemon 2010
– Models a customer order from a retail catalog (http://edn.embarcadero.com/article/31863)
PostgraduateProjectTitleThesisSubmitDate
PostgraduateProjectTitleThesisSubmitDate
PostgraduateProjectTitleThesisSubmitDate
Class-based Modeling: CRC
• Wir (1990): CRC modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.
• Ambler (1995): “A CRC model is really a collection of standard index cards 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.”
Badariah Solemon 2010
CRC: Example
Badariah Solemon 2010
PostgraduateProjectTitleThesisSubmitDate
PostgraduateProjectTitleThesisSubmitDate
PostgraduateProjectTitleThesisSubmitDate
• Pressman (2009) Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Responsibility: Collaborator:
Class: FloorPlan
Description:
Responsibility: Collaborator:
incorporates walls, doors and windows
shows position of video cameras
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
Wall
Camera
Behavioral Modeling
• Make a list of the different states of a system (How does the system behave?)
• Indicate how the system makes a transition from one state to another (How does the system change state?)– indicate event– indicate action
• Draw a state diagram (also known as statechart diagram) or a sequence diagram
Badariah Solemon 2010
The States of a System
Badariah Solemon 2010
• State —a set of observable circum-stances 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
State Representations
Badariah Solemon 2010
• In the context of behavioral modeling, two different 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
State Representations (cnt’d)
Badariah Solemon 2010
• The state of a class takes on both passive and active characteristics (de Champeaux et. al. in Pressman (2009)). – A passive state is simply the current status of all of an
object’s attributes.– The active state of an object indicates the current status
of the object as it undergoes a continuing transformation or processing.
State Diagram
Badariah Solemon 2010
• Notations:1. States are rounded rectangles. 2. Transitions are arrows from one state to another. 3. Events or conditions that trigger transitions are written beside the
arrows4. The initial state (black circle) is a dummy to start the action. 5. Final states (2 circles with inner black circle ) are also dummy states
that terminate the action.6. The action that occurs as a result of an event or condition is
expressed in the form /action. • E.g.: Cancel/Quit
State Diagram: Example #1
Badariah Solemon 2010
• http://edn.embarcadero.com/article/31863
Statechart Diagram: Example #2
Badariah Solemon 2010
• State Diagram for the ControlPanel Class (Pressman, 2009)
reading
locked
selecting
password entered
comparing
password = incorrect & numberOfTries < maxTries
password = correct
activation successful
key hit
do: validatePassword
numberOfTries > maxTries
t imer < lockedTime
timer > lockedTime
Behavioral Modeling: Sequence Diagram• An interaction diagram that details how
operations are carried out -- what messages are sent and when.
• Are organized according to time. The time progresses as you go down the page.
• The objects involved in the operation are listed from left to right according to when they take part in the message sequence.
Badariah Solemon 2010
Sequence Diagram
Badariah Solemon 2010
• Each vertical dotted line is a lifeline, representing the 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 of execution of the message.
• The diagram has a clarifying note, which is text inside a dog-eared rectangle
Sequence Diagram: Example #1
Badariah Solemon 2010
• Pressman (2009)homeowner control panel sensorssystem sensors
system ready
reading
request lookupcomparing
result
password entered
password = correctrequest activation
activation successful
lockednumberOfTries > maxTries
selecting
timer > lockedTimeA
A
Figure 8.27 Sequence diagram (partial) for SafeHome security function
activation successful
Sequence Diagram: Example #2
Badariah Solemon 2010
• A sequence diagram for making a hotel reservation• http://edn.embarcadero.com/article/31863
Summary
You have been introduced to:1. Guidelines of creating requirements analysis models.2. Two approaches to requirements modelling: structured
and object-oriented analysis approaches.3. Three classifications of modelling elements based on
object-oriented approach.4. Overview of several OO modeling elements such as use
case diagram, activity diagram, class diagram, state diagram, and sequence diagram.
Badariah Solemon 2010