Software engineering Lecturer: Giuseppe Santucci (Thanks to … · 2015-05-18 · Requirement...
Transcript of Software engineering Lecturer: Giuseppe Santucci (Thanks to … · 2015-05-18 · Requirement...
Software engineering
Lecturer:Giuseppe Santucci
(Thanks to Paolo Ciancarini)
Requirement engineering
1
Main issues
• Specification
• Requirements specification
• Conceptual models
• Requirements engineering
• UML
2
Specification (Specifica)• Explicit set of requirements:
– functional
– not functional• quality!
that must be satisfied by a material, product or service
• Detailed description of the design and development criteria of an artifact
• Detailed description of an algorithm, a Java class, an interface ...
• ...3
Kinds of specifications
• Requirements (between the study of feasibility and the design):
– Documents that define the system functionalities
– Agreement between customer and developer
• Design (during the design phase):
– Documents that define the project requirements
– Agreement between designers and implementers
• SW modules (during implementation):
– Document that defines what should be a SW module
– Agreement between implementers and programmers that will use it
4
What is a requirement?
• An abstract and vague description of a system
service or a constraint, or a detailed
specification of a system function
• This because requirements have a double face:
– They are the basis for bidding for a contract, so they
must be open to different interpretations
– They are the basis for granting a contract: then they
must include sufficient details to exclude unwanted
interpretations
5
Requirement specification• Definition of
– functionalities
– constraints
– performance
– interfaces
– quality criteria
– any other user-required feature
• Collected in a Software Requirements Specification document (SRS) that should be – complete
– accurate
– consistent
– unambiguous
– understandable
• to both the customer and developer
6
Goals of a SRS document
• Give feedback to the user
• Decompose a problem in independent sub-
problems
• Input for the design phase
• Input for the testing, verification, and validation
phases
• It is not a design document
• It says what, not how the system will do
7
Relevance of a SRS document
• Is the convergence of the points of view of the customer, user, and developer
• Provides a reference point for the validation of the final product
• Is a prerequisite for the SW quality:
– errors in SRS-system --> errors in the system
• Reduces development costs, as it facilitates the discovery of defects
8
Useful questions when writing a requirement
document
• What is the goal of the system?
• What is the goal of its users?
• How it will interface with users, hardware, and other software systems?,
• Which perfomance do we expect from the system?
• Which constraints should be satisfied?
9
Problems with Natural Language
• Specification writers and readers should use the same NL wording with the same meaning, but this is rarely the case
• A specification written in NL has always several alternative interpretations
• The requirements should be partitioned and ranked but NL is not suitable for this
10
Techniques for requirements elicitation
• Interviews and forms
• Requirements workshop
• Brainstorming
• Storyboards
• Use cases
• Prototyping
11
Main activities during the elicitation
• Identify the actors
• Identify the use cases
• Identify the non functional requirements
12
Requirement specification techniques
• Informal (a system model does not exist):• Natural language
• Interviews
• Questionnaires
• Conceptual models:• System and domain representations are included in the SRS
document
• Less or more formal
• Prototype:• Working
• Not working (paper based prototype)
13
Conceptual models
• Structured analysis:
– Data Flow Diagrams (DFD)
– Function decompositions
– Data oriented models, e.g., ER
• OO analysis:
– Decomposition of the system in domain "concepts"
– Modeling languages, e.g., UML
14
Kinds of specification languages
• Two orthogonal classification coordinates
• Semantics
– informal
– semiformal
– Formal
• Style
– operational
– descriptive
15
Semantics
• Informal specifications
– Natural language (good for the customer)
• Semi-formal specifications
– Comprehensible but ambiguous
– Graphical notation + natural language
– Widely used
• Formal specifications
– Not ambiguous
– Automatic consistency check
– Not easy to use
16
Style: operational• It describes the needed steps
• Example (sorting a vector): • A is a vector of n elements.
• The result of sorting A is a vector B of n elements:
– the first element is the minimum (if multiple elements have the same value, each of them is acceptable),
– the second element is the minimum in the vector of n-1 elements obtained by eliminating the minimum
– third and subsequent elements are defined in the same way, until all items are disposed in place
17
Style: descriptive
• It describes the desired properties in a purely declarative way
• Example (sorting a vector):• A is vector of n elements.
• The result of sorting A is a vector B n such that:
– it is an A permutation:
– it is ordered
– (in case the concept of permutation and sorting were not sufficiently clear, we can specify them with the same style, e.g., for every v [i], v [j] If i > j then v [i] > = v [j])
18
Some considerations
• Each of the styles (operational/descriptive) suggests a different way to implement the sorting
• It is not required to implement the sorting in any of that ways (although operational style strongly "suggests" a choice)
• Descriptive specifications are typically more general than operational but can lead to less efficient implementations
19
Example (Operational): DFD
• DFD (Data Flow Diagrams) are used to specify information system functionalities
• Four elements:
– Functions
– Data flow
– Data store
– Interface, producing or consuming data
Customer management
InfoCustomer
Employee
20
Example
management
Invoice
management
InfoCUSTOMERS
EmployeeInfoINVOICES
InfoITEMS
Customer
visualization andprinting
Invoice
Employee
21
Comments
• A DFD diagram can be refined, for example specifying the function "manage invoices"
• Symbol semantics is specified only by chosen identifiers
• In some cases this is sufficient, whereas in others you need a more precise definition (which is not part of the DFD)
22
Comments (2)• Control is not specified:
• D needs A, B and C to be executed, but can start only when only A it is done?
• (E) and (F) need the same data from D?
D
E
F
C
B
A
23
Comments (3)
• DFD is a semi formal model:
– syntax is formal
– semantics is not formal
24
Other operational example: finite state automata
• A FSA defines admissible states, inputs, and transitions:– S is the finite and not empty set of state
– I is the set of inputs
– d is the transition function S X I -> S
• Example: a lamp (2 states, 1 input)
Push button
OffOn
25
Push button
FSA with output
• <S, I, O, d, t, s0>
– S is the finite and not empty set of state
– I is the set of inputs
– 0 is the set of outputs
– d is the transition function S X I -> S
– t the function that computes the output S X I -> 0
– s0 is the initial state• Example: office phone (9 states, 6 inputs, 3 outputs)
26
Phone down
Waiting
first digit
lift phone/
internal tone
Waiting first
external digit
0/external tone
Waiting next
internal digit
1..9/-
hang up/-
Waiting next
external digit
1..9/- 0..9/-
0..9/-
valid number reached/
Waiting
connection
Remote phone
ringing
Talk
No conversation
is possible
busy/
busy tone
free/
ringing tone
lift remote phone/-
27
hang up/-
hang up/-
hang up/-
hang up/-
valid number reached/
Comments• Finite state automata are an example of a formal
specification (syntax and semantics are formally defined)
• They are particularly suited for describing control flow (that is missing in the DFD)
• They are suitable for describing synchronous systems and non-concurrent (for each instant of time the global state of the system should be defined and only a single transition may happen)
• Not easy to use!!!
28
Example (descriptive, semiformal) : ER model
Cliente Articolo
Fattura
0,N
1,1
1,N
1,N
n.pezzi
descaliquotacosto
#fatturadata emissionedata pagamento
29
Requirements engineering• Problem analysis
– Focus on: • problem
• constraints
• possible solutions
– The final goal is to understand what the system should do
• Requirements specification– Map requirements in a structured document (SRS)
• Requirements validation– Review requirements with
• a) technical people and
• b) customer (contract review)
30
Categories of requirements
• Functional requirements: describe the behavior and interactions between the system and its environment– Eg.: the e-learning platform tracks student’s activities
– Eg.: the platform is used for both reading texts and participating to exams
• Non functional requirements: describe the system properties visible to the users and not directly related to its functional behavior– Eg.: the platform has to manage up to 100 students concurrently
– Eg.: If a user posts a question he must have an an answer in max 48h
– Eg.: The platform has to be available 24h per day 7 days per week (24/7)
• Constraints(“Pseudo requirements”): defined by the stakeholders– Eg.: The programming language will be Java
– Eg.: The platform must deal with documents written in Office Word on Vista
31
What is NOT a requirement?
• System structure (or “architecture”)
• Implementation technologies
• Development method
• Development environment
• Programming language
• Reuse and portability concerns
• Instead the real world domain descriptions are included
in the requirement document
32
Conflicts and priorities
• Different stakeholders have different priorities
• Final users have expectations different from
funding people
• Difficult to anticipate all problems and conflicts
• Prototyping is a useful technique to mitigate
conflicts and anticipate problems
33
Using NL: the library example
A library is managed by some staff and has some
users who can search and borrow books. A user
can keep a book for one month, then has to give it
back. The library contains one million books, and
the staff buy about 10.000 books each year. A new
book cannot be borrowed before six weeks. If a
book is not available, the request is put in a waiting
list. When a book is lost it is deleted from the
catalog and its waiting list is canceled…
34
The library example
– “The system shall maintain records of all library materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disks and CD-ROMS.”
– “The system shall allow the users to search for an item by title, author, or ISBN.”
– “The system’s user interface shall be displayed using Firefox 2 and above”
– “The system shall support at least 20 transactions per second.”
– “There should be no more than 3 clicks from homepage to reach search results.”
– “The access permissions for system data may only be changed by the system’s data administrator”
35
Using structured NL
• The NL can be restricted in order to increase clarity and precision
• A structured NL can avoid some typical ambiguities by constraining the requirement documents to have some structure
• Usually a structured NL specification is based on a pre-defined form
36
Example
ECLIP SE/W orkstation/Tools/DE/FS/3.5.1
Func tion Add node
Desc ription Adds a node to an existing de sign. The user selects the ty pe of node, and its position.W hen a dde d to the design, the node bec ome s the current selection. The user choose s the node position bymoving the cursor to the a rea whe re the node is added.
Inputs Node ty pe , Node position, De sign identifie r.
Sourc e Node ty pe a nd Node position are input by the user, De sign identifie r from the database.
Outputs Design ide ntifier.
Destination The de sign database. The design is com mitted to the database on c omple tion of theoperation.
Requires Design graph rooted at input design ide ntifier.
Pre-c ondition The de sign is open and display ed on the user' s sc reen.
Post-condition The de sign is uncha nge d apa rt from the addition of a node of the specified typeat the given position.
Side -effec ts None
Definition: ECLIPSE/W orkstation/Tools/DE/RD/3.5.1
37
Non-functional requirements• Non-functional requirements are criteria usable to
judge the operation of a system, rather than its specific behaviors
• They define the critical properties of a system. Examples: reliability, throughput, answer time, security, user-friendliness
• Some non-functional requirements put constraints on the system development process or infrastructure
• Non functional requirements are often more important than functional ones, because if they are not satisfied the system will be refused
38
Tracking techniques
• Assign a unique id to each requirement
• Cross reference of requirements in a traceability matrix
• Hypertext management of requirements in order to support effective navigation mechanisms
40
The IEEE 830-1993 standard
• The Software Requirement Specification
document (SRS) must correctly define all of
the software requirements, but no more
• Eight qualities:1. Unambigous
2. Correct
3. Complete
4. Verifiable
5. Consistent
6. Modifiable
7. Traceable
8. Ranked (for importance and/or stability)
41
SRS document characteristics (1)
• Correctness– Is it representing requirements in a correct way?
• Completeness– Internal: any used concept (acronym) must be defined
– With respect to requirements: all requirements must be included in the SRS
– Typically it is an incremental process
• too many details
• some requirements rise during the development
• Consistency– No contradictions
42
SRS document characteristics (2)
• Non-ambiguity
– Any concept, requirement has a unique interpretation
• Verifiability
– A precondition is the non-ambiguity
– Same properties (BUT not all) are verifiable in a rigorous way
• To handle the requirements we need
– Modifiability (e.g., not duplications)
– Traceability (e.g., section numbering, statement numbering, requirement numbering)
43
SRS document characteristics (3)
• Traceability– The source of each requirement is clear and it is possible to
reference it in the future (def. IEEE)
– Traceability matrixes • requirements/functionality
• requirements/subsystems
• requirements/interfaces
• dependency among requirements
– Forward traceability: requirement->> code
– Backward traceability: code-->> requirement
44
SRS structureStandard IEEE 830-1993:
• Table of contents
• 1.Introduction
– 1.1. Purpose
– 1.2. Scope
– 1.3. Definitions, Acronyms, and Abbreviations
– 1.4. References
– 1.5. Overview
• 2.General Description
– 2.1. Product Perspective
– 2.2. Product Functions
– 2.3. User Characteristics
– 2.4. General Constraints
– 2.5. Assumptions and Dependencies
45
SRS structure (2)• 3.Specific Requirements
– 3.1. External Interface Requirements•3.1.1. User Interfaces
•3.1.2. Hardware Interfaces
•3.1.3. Software Interfaces
•3.1.4. Communications Interfaces
– 3.2. Functional Requirements / Objects
– 3.3. Performances Requirements
– 3.4. Logical database requirements
– 3.5. Design Constraints•3.5.1 Standard Compliance
•3.5.2. Hardware Limitation
•…
– 3.6. Attributes (quality)•3.6.1 Reliability
•…
– 3.7. Other Requirements
• 4. Appendixes
46
SRS structure (3)
• 3.2. Class/Object
– 3.2.1. Class/Object 1• 3.2.1.1. Attributes
– 3.2.1.1.1 Attribute 1.1
– …
• 3.2.1.2 Functions (methods)
– 3.2.1.2.1 Functional requirement
– …
• 3.2.1.3. Messages (received or sent)
– 3.2.2. Class/Object 2
• …
47
UML
• general concepts
48
UML introduction
• Method convergence history
• Main models within UML:
Use Case Diagram
Class Diagram
Sequence Diagram
Collaboration Diagram
Activity Diagram
State Diagram
Component Diagram
Deployment Diagram
49
Unified Modeling Language
• Notation/standard for:• Expressing software requirements
• Expressing software architecture
• Expressing the structure and behavior of the software
– Current version, maintained by OMG (Object Management Group): 2.4.1 (August 2011) http://www.omg.org/spec/UML/
50
Unified Modelling Language
• UML is a graphic notation system (with clear syntax and semantics ) for modeling OO software applications
• UML is not a process, or a proprietary notation: it is an OMG standard (Object Management Group), defined using a metamodel
• It includes: – Views (show various faces of the system: user, operational, structural,
etc., also in relation with the development process)
– Diagrams (graphs that describe the contents of a view)
– Modeling Elements (constructs used in the diagrams)
51
Metamodel ?
52
Convergence of methods– 1980s, first OO methodologies
– 1989-1994 more than 50 languages for modeling OO applications are presented
– 1994 Grady Booch and James Rumbaugh begin their unification work : Booch + OMT
– 1995 : Unified Method 0.8, in the same year, IvarJacobson joins the group bringing his OOSE: the unification of approaches has started
– 1996 UML version 0.9 and 0.91 are released and many other partners join to support UML
– 1997 : UML 1.0 and OMG adopts it as standard ...
– June 99--2015: 1.1-1.2-1.3-1.4-....2.5 beta 2 ....
53
UML evolution • 1995 UML published by Rational
• 1997 UML 1.1: OMG standard
• 1999 UML 1.3: OMG
• 2001 UML 1.4: OMG
• 2003 UML 1.5: OMG
• 2004 Standard ISO/IEC 19501,
• 2007 UML 2.1.2: OMG
• 2010 UML 2.3
• 2011 UML 2.4.1
• 2011-2015 resting / minor details
– Superstructure: It defines the user level constructs required for UML
– UML Infrastructure: The infrastructure defines base classes that form the foundation not only for the UML superstructure, but also for MOF (Meta Object Facility) . It defines the foundational language constructs required for UML
– UML Object Constraint Language (OCL): This allows setting of pre- and post-conditions, invariants, and other conditions
– UML Diagram Interchange: This specification extends the UML metamodel with a supplementary package for graph-oriented information, allowing models to be exchanged or stored/retrieved and then displayed as they were originally.
54
UML evolution
Booch
Unified Method 0.8
UML 1.1
OMT
(Rumbaugh)OOSE/Objectory
(Jacobson)
UML 0.9
OOPSLA ´95
WWW - June ´96
Beta version OOPSLA ´96
OMG, gennaio ´97
Basic document
Three books (from the 3
Amigos):
-- User Guide
-- Reference Manual
-- Process Book
Only on Web
Other methods
Public
feedback
UML 1.5
OMG, 2001
IBM compra Rational, 2002
UML 2.5OMG 2007-2015
Standard ISO/IEC 19501
UML 1.4
55
Some UML partners• Digital Equipment. http://www.dec.com
• Hewlett-Packard http://www.hp.com
• i-Logix http://www.ilogix.com
• ICON Computing http://www.iconcomp.com
• MCI Systemhouse http://www.systemhouse.mci.com.
• Microsoft http://www.microsoft.com
• Oracle http://www.oracle.com
• Rational Software http://www.rational.com/uml
• Texas Instruments http://www.ti.com/software http:// www.ti.com/software/cbd.htm
• Unisys http://www.unisys.com
56
Some software tools that use UML
57
UML ?
• Can describe
– The use of the software
– How it works
– How to build it
– The agreement (contract) between customer and developer
58
13 Canonical diagrams
(Superstructure)
59
http://www.agilemodeling.com/essays/umlDiagrams.htm
Superstructure
60
Main UML diagrams
• Use Case Diagram
– It represents relationships among use cases and actors
– A system use case describes a system that automates abusiness use case or process. It is normally described at thesystem functionality level (for example, "create voucher") andspecifies the function or the service that the system providesfor the actor. The system use case details what the system willdo in response to an actor's actions. For this reason it isrecommended that system use case specification begin with averb (e.g., create voucher, select payments, exclude payment,cancel voucher). An actor can be a human user or anothersystem/subsystem interacting with the system being defined.
Actor 1 use caseActor 2
61
Use cases• An Use Case is a system view showing his behavior as it will appear to
users
• Partition functionalities in transactions ('use cases ') meaningful to users (' actors ').
• Consists of typical scenarios-interactions between a user and a computer system
• Properties: – Shows functions visible to the user
– Achieves objectives specific to the user
– It does not represent the order or the number of times a function is executed
• It is built talking with the user
• It is used to construct structural models, operational, and also to prepare test cases
62
An example• Phone selling system
63
Main UML diagrams
• Design model: Class Diagram (Static Structure Diagram)
– The diagram that shows the static elements of a model along with their properties and relationships among them i
– It is used by the developers
• It starts the description of how the system will be built
64
Example
• Shows which sw components are used and how relate to each other
Check
Number: StringDate : Date
Status : CheckStatus
ContoCorrente
Count# : String
Balance : Double
CheckBlock()
SetAuthorization()
Cash
Material object
Import : Double
Object
Divisa : Currency
On
65
Main UML diagrams• Design model: Behavioural Diagrams (Interaction Diagrams)
– Sequence Diagram
• The diagram that represents the interactions between objects by arranging them in sequence. In particular it shows the objects participating in the interaction and sequence of the messages exchanged.
– Collaboration Diagram
• The diagram that shows interactions organized around system objects and links between these objects.
66
Sequence diagram
It shows the
object interaction
temporal
sequence
67
time
Control
Object's life
Collaboration diagram
Shows the
interactions
among
objects
and their
visibility
68
Main UML diagrams
• Design model: Behavioral Diagrams
– State Diagram
• It described, in a detailed way, an object behaviour, through a FSA
– Activity Diagram
• It describes parallel processes
69
An object status
• A State transition diagram shows:
– the life cycle of an object of a class
– the events that cause a transition from one state to another one
– the actions resulting from a change of state
• these diagrams are created only for objects with significant dynamic behavior
70
Main UML diagrams • Example: A University Course
InitializationOpen
entry: Register student
exit: Increment count
Closed
Canceled
do: Initialize course
do: Finalize course
do: Notify registered students
Add Student / Set count = 0
Add student [ count < 10 ]
[ count = 10 ]
Cancel
Cancel
Cancel
71
Main UML diagrams
• Implementation Model
– Component Diagram• It represents the system software modules (components) and
their dependencies
• A component can be:
– Source code
– RunTime library
– Executable code
– Deployment Diagram• It describes the run-time component locations and the
computing network
72
Course Courses
Student Professor
Component diagram
Course.dll
Person.dll
Secretery.exeContability.exe
stereotypes
<<executable>>
<< library>>
<< table>>
<< file>>
<< document>> 73
Components
• UML component icon:
• A software component is "a non-trivial software module: a package or subsystem that has a precise function and well delineated, and can be integrated into a well defined architecture "
• key concepts in this definition: – non-trivial function
– well outlined
– precise function
Payment
System
74
The phisical system
• The deployment diagram shows the run time configuration of sw components and elements of software processes that live in them
• The deployment diagram shows the distribution of the components within the enterprise
75
Deployment diagram
76
Deployment diagram with components
77