CSEB233 Fundamentals 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

Communication

Action

Requirements Engineering

Task

Inception Req. Elicitation Req. Analysis & Negotiation Req. Specification Req. Verification and Validation Req. Management Planning Modeling Construction Deployment

Requirements Modeling

Design Modeling

Context Modeling Technical Modeling

Badariah Solemon 2010

Requirements/Analysis Model

• • • A graphical representations of business processes, the problems to be solved, and the new proposed product (software).

Objectives: 1.

2.

3.

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.

Software specification Bridges the gap between a software specification and a software design.

Analysis Model Design Model

Badariah Solemon 2010

Rules of Thumb

• 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

Badariah Solemon 2010

Requirements Modeling Principles

• • • • • Principle #1. The information domain represented and understood.

of a problem must be Principle #2. The functions be defined. that the software performs must 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 partition ed 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 .

Badariah Solemon 2010 *Recap from chapter 4

Domain Analysis

• 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 . . .”

Badariah Solemon 2010

What is Domain Analysis?

• •

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.

Badariah Solemon 2010

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 Modeling

1. 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

•

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

Badariah Solemon 2010

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 associations and objects , attributes and dependencies. , operations , • 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

University Library System

Badariah Solemon 2010

Use Case: Example #2

• Airline Reservation System

Airline Reservation System

Check In Passenger Ticket Clerk Add New Reservation Cancel Reservation

Badariah Solemon 2010

Relationships of Use Cases

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.

Badariah Solemon 2010

Relationships of Use Cases: Example #1

Airline Reservation System

Ticket Clerk «uses»

B A

«uses» Weigh Luggage «extends» Check In Passenger

B A

Assign Window «extends» Seat Assign Seat

A A

Add New Reservation «uses»

B

«uses» Check Seat Availability Assign Aisle Seat

B

Cancel Reservation Record Passenger Information

Badariah Solemon 2010

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.

Purpose

To represent an activity To represent a flow To represent branching decisions To indicate all parallel activities within the system.

Badariah Solemon 2010

Activity Diagram: Example #1

ent er password and user ID • Pressman (2009), pp 162 valid passwor ds/ ID invalid passwor ds/ ID selec t major f unc t ion ot her f unct ions m ay also be select ed selec t surv eillanc e prompt f or reent ry no input t r ies r em ain input t r ies r em ain t hum bnail views select a specif ic cam er a selec t spec if ic c amera - t humbnails selec t c amera ic on v iew c amera out put in labelled window prompt f or anot her v iew exit t his f unct ion see anot her cam er a

Badariah Solemon 2010

• •

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

h o m e o w n e r c a m e r a i n t e r f a c e

• Pressman (2009), pp 163 ent er pas sword and us er ID s elec t m ajor f unc t ion o t h er f u n ct io n s m ay also b e select ed select s urveillanc e valid p asswo r d s/ ID in valid p asswo r d s/ ID prom pt f or reent ry in p u t t r ies r em ain n o in p u t t r ies r em ain t h u m b n ail views select a sp ecif ic cam er a s elec t s pecif ic c am era - t hum bnails selec t cam era icon generat e video out put view c am era out put in labelled window prom pt f or anot her view exit t h is f u n ct io n see an o t h er cam er a

Badariah Solemon 2010

Swimlane: Example #2

Badariah Solemon 2010

Class-based Modeling: Class Diagram

1. 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

• • To model a class, use a rectangle with three sections: 1.

name of the class (top) 2.

list of attributes (middle) 3.

methods (bottom). Name of class – – Example: Student a Student class which has attributes StudentID StudentID Email , and , Firstname , Lastname ContactNumber . List of , Lastname Email ContactNumber Student perform operations such as RegisterCourse , DropCourse , and PrintTranscript .

RegisterCourse() DropCourse() PrintTranscript() List of methods

Badariah Solemon 2010

Class Diagram: with Several Classes

• • 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).

Badariah Solemon 2010

Class Diagram: with Several Classes (cnt’d)

Indicator Meaning 0..1

Zero or one 1 0..* 1..*

N

0..

n

One only Zero or more One or more Only

n

Zero to (where

n n

(where > 1)

n

> 1) 1..

n

One to

n

(where

n

> 1) • Example: Student StudentID Firstname Lastname Email ContactNumber 0..* attended by Registered 0..* Course CourseCode CourseName CreditHours Fees RegisterCourse() DropCourse() PrintTranscript()

Badariah Solemon 2010

Class Diagram: with Several Classes (cnt’d)

2. Inheritance/generalisation

• Different classes usually share and/or methods. the same attributes • To avoid repeating the same attributes and/or methods, you need to take advantage of the inheritance mechanism. (also known as generalisation) • 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.

Badariah Solemon 2010

Postgraduate ProjectTitle ThesisSubmitDate

Class Diagram: with Several Classes (cnt’d)

• Example: Student StudentID Firstname Lastname Email ContactNumber RegisterCourse() DropCourse() PrintTranscript() 0..* Registered attended by 0..* Course CourseCode CourseName CreditHours Fees Undergraduate CreditLimit * ATM Case Study Postgraduate ProjectTitle ThesisSubmitDate

Badariah Solemon 2010

Postgraduate ProjectTitle ThesisSubmitDate

Class Diagram: Example

– Models a customer order from a retail catalog (http://edn.embarcadero.com/article/31863)

Badariah Solemon 2010

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 left and the collaborators on the on the right.”

Badariah Solemon 2010

Postgraduate ProjectTitle ThesisSubmitDate

CRC: Example

• Pressman (2009)

Class: Class: Class: Class:

Description: FloorPlan

Responsibility: Responsibility: Responsibility: Responsibility:

defines floor plan name/type manages floor plan positioning

Collaborator: Collaborator:

scales floor plan for display scales floor plan for display incorporates walls, doors and windows shows position of video cameras

Collaborator: Collaborator:

Wall Camera

Badariah Solemon 2010

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

• • • • 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

Badariah Solemon 2010

State Representations

• – 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

Badariah Solemon 2010

State Representations (cnt’d)

• – 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.

Badariah Solemon 2010

State Diagram

• Notations: 1.

States are rounded rectangles . 2.

3.

4.

5.

6.

Transitions are arrows from one state to another. Events arrows or conditions that trigger transitions are written beside the 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

Badariah Solemon 2010

State Diagram: Example #1

• http://edn.embarcadero.com/article/31863

Badariah Solemon 2010

Statechart Diagram: Example #2

• State Diagram for the ControlPanel Class (Pressman, 2009) t imer < lockedTime locked t imer > lockedTime key hit reading password = incorrect & numberOfTries < maxTries comparing numberOfTries > maxTries password ent ered do: validat ePassw ord password = correct select ing act iv at ion successful

Badariah Solemon 2010

• • •

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

• • • • 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

Badariah Solemon 2010

Sequence Diagram: Example #1

• Pressman (2009) h o meo w n er syst em read y co n t ro l p an el A p assw o rd en t ered read in g co mp arin g req u est lo o ku p resu lt password = correct num berOf Tries > m axTries lo cked A t imer > lo cked Time syst em req u est act ivat io n select in g act ivat io n su ccessfu l act ivat io n su ccessfu l Figure 8 .2 7 Sequence diagram (part ial) f or

Saf eHome

securit y f unct ion

Badariah Solemon 2010

Sequence Diagram: Example #2

• • A sequence diagram for making a hotel reservation http://edn.embarcadero.com/article/31863

Badariah Solemon 2010

Summary

You have been introduced to: 1.

2.

3.

4.

Guidelines of creating requirements analysis models.

Two approaches to requirements modelling: structured and object-oriented analysis approaches.

Three classifications of modelling elements based on object-oriented approach.

Overview of several OO modeling elements such as use case diagram, activity diagram, class diagram, state diagram, and sequence diagram.

Badariah Solemon 2010