Requirements Engineering

System modeling notations and techniques

RE process framework
User requirements 1 Elicitation 2 Domain knowledge User reqs spec Specification 4 Domain knowledge User feedback 5 3 Validation

Problem domain

1: knowledge 2: request more knowledge 3: requirements models 4: validation results 5: models to be validated

Elicitation: Guidelines

Elicitation should identify A representation of relevant information A model of software behaviour Elicitation should consider how the system Will be structured (from the user perspective) Will provide functionality Complex systems must be partitioned hierarchically Elicitation is then carried out separately on different parts
3

System Modeling Techniques

Object-oriented model: Use Cases, Activity diagrams, Class diagrams, CRC cards. Functional model: SADT (Structured Analysis and Design Technique), dataflow diagrams Data-oriented model: Entity-Relationship diagrams (akin to class diagrams) Dynamic model: state transition diagrams, Petrinets

Levels of formality
Informal specification Based on natural language (ambiguous) Formal specification Based on mathematical language Semi-formal specification Made of both informal and formal parts

Use Case Diagram

Use Case Diagram

Semi-formal notation Specifies the interactions between the system and the external world Useful to Oblige the analyst to state well-defined boundaries between system and external world Organize system functions into elements (use cases) on which attention is focused Supply a first basis for the specification of system structure from the user perspective
7

Elements of a Use Case Diagram

Actor

Someone (user) or something (external system, hardware) that Exchanges information with the system Supplies input to the system, or receives output from the system

Use Case

A functional unit (functionality) part of the system

Relations among Use Cases

Use Case Actor

Interaction. Models: Which actors participate in a use case Where execution starts

Use Case Actor

<<include>> Use Case A Use Case B

Usage. Models that a selected functionality is used in the context of another functionality (one is a phase of the other)

Use Case A

Use Case B

Generalization. Defines a functionality as extension of another already existing functionality (special case)
9

At the beginning of the semester, the students office has to supply the students with the list of available courses through a system of online registration. Each student must select 4 available courses, and state two possible alternatives. Each course must have from 3 to 20 students: courses with less than 3 students are cancelled, and those with more than 20 are split. In the previous period, the professors access the system online to insert their courses in the list, while in the period after students selection they access to check current state of enrolled students to their courses. After the selection period, the system creates def. lists, by solving all anomalies (courses with less than 3 or more than 20 selections) and it sends them to administrative office to state enrolment charges due by each student. The students access the system for the list of their courses 10 All user interactions are authenticated

Online Courses

UCD for Online Courses

Administrative Office

Course Selection <<include>>

Request Students List <<include>>

<<include>> Students

User Authentication <<include>>

Professor

Request Course List

Insert Course

11

Further example of relations Include/Generalize

<<include>> Hotel Booking Check availability

<<include>>

Customer Acquire Customer data <<include>>

Acquire Credit Card data

Hotel Booking guaranteed by Credit Card

12

Domestic Security System

Once installed, the system monitors all connected sensors (of movement, entrance, smoke), and interacts with the user though a keyboard and a display inside a dedicated control panel. During installation, the control panel is used to configure the system. Each sensor is assigned with a unique numeric code and the phone number of the monitoring service to call in case of events related with a sensor. It also defines a password for activate/deactivate the system. In case of an event related with some sensors, the system displays a message and produces an acoustic alarm. After a period (defined during user configuration) the system calls the phone number associated with the sensor. Should the number be busy, the system repeats the call every 20 seconds.
13

UCD for Domestic Security System

<<include>> Set password User Configuration <<include>> Configure sensor

Sensor

Event management Acoustic Transmitter

Monitoring Service
14

Data Flow Diagram

Dataflow Diagram

Semi-formal notation Popularized in the 70s and 80s by Yourdon and Constantine Two step process: Structured Analysis (SA) and Structured Design (SD) SA: dataflow diagrams SD: structure charts

16

Entities in a data flow diagram

external entities processes data flows data stores
Entity name Function name

Data label Data label

17

Context Diagram
Front-Desk Personnel
check-in/ check-out form request for information bill update bill

Catering Personnel
order

Management

reports reservation

Hotel Reservation System

order confirmation

update bill

Room Service Personnel

Guest

18

Dataflow Diagram (Fragment)

log bill

Check Out
client

reservation

Check out decomposition: calculate bill, generate bill, generate log info
19

Dataflow Diagrams

Dataflow diagrams can be further elaborated with Data dictionaries: detailing data stores and flows Mini-specs: detailing functional aspects

20

Activity diagram

Activity Diagram

Formal notation In a conceptual model it represents the activities (sub-tasks) that needs to be done Use cases and a hierarchical task decomposition can be represented/visualized in activity diagrams It can pinpoint the interactions between different activities (e.g. tasks and use cases)

22

Activity Diagram (cont.)

Start Point End Point Synchronization Bar
Do Something

Activity Decision Activity

[condition]

Guard
23

Activity Diagram (cont.)

Construct an activity diagram for order processing. When an order arrives, payment must be authorized and all ordered items must be in stock (otherwise the order is suspended and items are reordered). When all items are present and payment took place, the order is dispatched to the customer.

24

Activity Diagram (cont.)

Receive order [for each line item in stock] Cancel order [failed] Authorize Payment Check Line Item [in stock] Assign to Order [need to reorder] Reorder Item

[stock assigned to all line items and payment authorized] Dispatch Order

25

Activity Diagram (cont.)

What is not modeled with activity diagrams Links between actions/responsibilities and objects (use CRC Cards) Collaborations between objects (use interaction diagrams) Object life cycle (use state diagrams)

26

Class diagram

Type level

Classes and Class Instances

How to model a system able to open new Faculties (having a name and an athenaeum) and managing enrolment of new students (having a name and ID)?

28

Classes and Class Instances

Student ID Name 1..n matriculate() enrol 1 open() Faculty Name Athenaeum

Class level Instance level

Albert Einstein Galileo Galilei Martin L. King

association

X X X

Engineering Architecture Computer Science Economics association instances (or links) Arts
29

What is a Class Diagram

A Class Diagram describes The types of objects in the system The types of static relationships among them We draw Class Diagrams under three perspectives Conceptual Software independent Language independent Specification Focus on the interfaces of the software Implementation Focus on the implementation of the software
30

Class

Class Name Window - visible - position - size + resize() + display() + hide() + move() Attributes

private

Operations

public

31

Class
Extensibility mechanisms to add new elements to UML Stereotypes A domain-specific or user-defined class level element For classes <<Table>> <<Interface>> And associations <<communicate>> <<subscribe>> Tagged values A pair describing a property of a model element <name,value>
32

Class ...
Attribute syntax attrName : attrType = initialValue Operation syntax Visibility opName (argName:argType=DefaultValue, ):returnType

Interfaces Utilities: no instances!

<<stereotype>> ClassName publicState : UserDef = tested privateAuthor : UserDef = pam ProtectedOp(argname) : return

<<Interface>> ClassInterface B

<<utility>> Math

<<Interface>> ClassInterface A
33

Associations

Structural relationships between classes of objects Association multiplicity Number of potential participating objects 1, 0..1, M..N, *, 0..*, 1..* Class multiplicity number of classes involved in the association binary, ternary, N-ary

34

Association Multiplicity indicators

n * m..n
Exactly n Zero o more Between m and n (included)

m..* 0..1

From m above Zero or one (optional)

35

Class Multiplicity: Binary Associations

Exam -date -subject -studentsList +print() +enrolStudent() * Takes-place-on 4 1 ExamDate -day -month -year -time +print()

Multiplicity Name of relationship

Student -name -surname -code +print()

Lesson * +attended +print() -subject -teacher

3..10

attends 4 +attendee

Roles
36

In other words Use

Two classes are in USE association (B uses A) if instances of B can send messages to instances of A An object uses another object if able to send messages to it
+Employer Company +apply() -planInterviews() 0..1 hiring +Candidate Person 1..* +interview() +seekJob()

37

Associations (cont.)
Association naming and direction To facilitate model understanding Role naming End of an association When Many associations connect two classes One association connects the same class more than once

38

Association Naming
User Profile 1 user Information 1 User 0..* subscription registration constraints 1 0..* user service information 0..* Service Profile +userPreferences 0..*

Subscription

1..* Terminal -Address +Type

0..* supports default 1..* 1..* Service +startService()

39

Association Direction and Role Naming

Passengers

Plane

? ?

? ?

Person

Pilot

40

Associations (cont.)

Constraints on associations Association classes

Plane * * Passengers {xor} Pilot Delivers * 1..2 Person

Student

Assignment {time<120}

Grade
41

Aggregation
Asymmetric association Person Criteria implying aggregation A class is part of another class Attribute values of a class propagate to the attribute values of another class An action of a class implies an action of another class Instances of a class are subordinates of instances of another class
+owner co-owner 1..* 0..* Building

42

Aggregation

Composition as physical containment

Aggregate 0..1 *

Component

Example

aggregate class Car +start() 1 Engine 1 #start()

43

Aggregation
Model the system allowing students to enroll in exams Each exam date includes a date made of day, month. Year and time; it is associated with a subject. On request, a student can enroll in a selected exam. The system further allows to Move the date of an exam Print out information about each object
44

Aggregation
Exam - studentsList - room +print() +manageEnrollment() +move() * Student * -name -surname -code +print() +enroll()
45

* *

ExamDate -day -month -year -time +print() +changeState()

Lesson -subject -teacher +print()

Generalization

Classification relationship between a general element and a more specific element Inheritance in OO programming Construct a class from another Sharing attributes, operations and constraints Visibility between superclass and subclass Single (Java) or multiple (C++) Inheritance and Delegation

46

Pure Specialization (Extension)

Window

Base class (superclass)

-title -position -size +resize() +move() +close()

Generalization association
Text Window
-text

inherits from derives from is a

Image Window

Derived classes (subclasses)

-image

+replaceText() +deleteText()

+refresh() 47

Class Hierarchy
Build the inheritance associations existing among the following objects: Living Being Human Being Flower Animal Vegetable Merchant Floweriest Client Suggestion Group elements in classification sets, and then build the generalization hierarchy 48

Class Hierarchy
Living Being

Animal

Vegetable

Human Being Flower Merchant Client

Floweriest
49

Impure Specialization
Sometimes we want to define exceptions to the specialization mechanism Overriding To modify inherited properties Usually for operation implementations (methods) Never for interfaces A subclass implements the interface of all its superclasses

50

Impure Specialization (Overriding)

Person -name -surname +print()

Employee -qualification -salary +print() -ID

Student

+print()

51

Multiple Inheritance

A class is derived from many superclasses For its support, the language has to solve possible conflicts What happens if both superclasses support the same message?

52

Properties of Inheritance
Transitivity If B derives from A, then B derives from all superclasses of A When multiple inheritance is not supported The inheritance hierarchy becomes a tree We can always transform inheritance in delegation associations

53

Eliminating Multiple Inheritance

Displ ayabl e Object color coordinates filled perimeter() Polygon vertices translate() rot ate() peri meter()
Displayable Object color coordinates filled perimeter()

Displayable Polygon

Polygon vertices translate() rotate() perimeter()

Displayable Polygon

delegation

54

Abstract classes

Base for extensible systems The set of general mechanisms is described according to the specifications of the abstract classes, without considering specific features gathered within concrete classes Abstract property Applicable to both classes and operations (the method to be defined in subclasses) An abstract class cannot be instantiated directly It is allowed for types, packages and stereotypes
55

Abstract classes

Astratto properties operationOnly()

Abstract Class Name (in italic)

No methods allowed!

56

When to use Class Diagrams

Do

Use it always! Base for all OO methods Base for tool-implemented code generation Fit the perspective you are in Conceptual Model during requirements engineering Specification models during design Implementation models during language-specific phases Showing a particular implementation technique
57

When to use Class Diagrams (cont.)

Do Not Use all constructs (start from basics and use advanced ones only if needed) Draw models for everything Focus on key aspects in few diagrams Go down to implementation details too early

58

How to derive a Class Diagram

Finding the classes: examine the use cases A noun could be a class. Example: When we receive an order, we check each line item on the order to see if we have the goods in stock. If we do, we assign the goods to the order. If this assignment sends the quantity of those goods in stock below the reorder level, we reorder goods. What other classes can we identify?

59

Finding the classes: candidate objects Order Supply Line Item Reorder Level (attribute) Product, Good (= Product) (individual instance) Product Description (meta level object describing instances) Stock (do we need this one?) Company (not in use cases) Customer (not in use cases, but needed to check the creditworthiness) Invoice (not in use cases)

How to derive a Class diagram (cont.)

60

Finding the classes: carefully consider the candidate list Equate synonymous terms Product and Good Product Eliminate operation names, if possible E.g. Reorder Be careful in what you really mean Is it Product rather than Product Description? Eliminate individual objects (as opposed to classes) Reorder Level attribute of Product Description Eliminate implementation constructs E.g. software Replace or eliminate vague terms system computer

How to derive a Class diagram (cont.)

61

How to derive a Class diagram (cont.)

TradingCompany
1

* Customer *
1

Order * Line Item

* P1

Product *

1 1

ProductDesc PD1

P2

PD2

62

Assigning Responsibilities to Classes

At this point, we have derived activity and class diagrams from performing task analysis and developing use cases. The next step is to assign responsibilities to classes. CRC Cards can be used for this purpose.

63

CRC Card

A CRC (Class-Responsibility-Collaboration) card is an index card with three elements Class: element under analysis (a class as usually used for object-oriented analysis) Responsibility: a high level description of the purpose of the class Collaboration: the classes involved to fulfill a responsibility Very simple yet very useful

64

CRC Card (cont.)

Class
Order

Collaborators
OrderLine Customer

Responsibility
Check if item in stock Determine price Check for valid payment Dispatch to delivery address

But, how are responsibilities carried out? Who is collaborating with whom?
65

CRC Card (cont.)

Elaborate the CRC Cards for the system allowing students to enroll in exams.

66

Prototyping the User Interface

Use rapid prototyping tools (e.g., Visual Basic, Java Beans compliant) Use cases are the starting point

67

Assessment of Risks

A risk is a possible future negative event that may affect the success of an effort. Examples are Requirements Technological Skills Political

68

RE Techniques Interactions
From a task model (conceptual model, focus on the user) to use cases (system model, focus on user using a system). Tasks act on things (e.g., entities, objects) class diagrams The relation between actions and objects can be defined with CRC cards, which can be refined in interaction diagrams

69