Génie Logiciel et Gestion de Projetsssel.vub.ac.be/Members/RagnhildVDS/INFOF407/SRE.pdf ·...
Transcript of Génie Logiciel et Gestion de Projetsssel.vub.ac.be/Members/RagnhildVDS/INFOF407/SRE.pdf ·...
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Génie Logiciel et Gestion de Projets
Software Requirements Engineering
1
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Software RequirementsEngineering
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Roadmap
• Software Requirements
• User requirements versus system requirements
• Functional and non-functional Requirements
• The software requirements document
• Requirements Engineering Processes
• Feasibility studies
• Requirements elicitation and analysis
• Requirements validation
• Requirements management
3
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Roadmap continued
• Models
• Behavioural models
• Data models
• Object models
4
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Software Requirements
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Engineering
6
• The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
What is a Requirement?
• It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.
• This is inevitable as requirements may serve a dual function
• May be the basis for a bid for a contract -> must be open to interpretation;
• May be the basis for the contract itself -> must be defined in detail;
7
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
User vs System Requirements
• User requirements
• Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
• System requirements
• set out the system’s functions, services and operational constraints in detail. The system requirements document should be precise. It should define exactly what is to be implemented. It may be part of a contract between client and the software developers.
8
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Functional requirements
• Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
• Depend on the type of software, expected users and the type of system where the software is used.
• Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.
9
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Functional req. examples
• The user shall be able to search either all of the initial set of databases or select a subset from it.
• The system shall provide appropriate viewers for the user to read documents in the document store.
• Every order shall be allocated a unique identifier which the user shall be able to copy to the account’s permanent storage area.
10
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Functional req. problems• Problems arise when requirements are not
precisely stated.
• Ambiguous requirements may be interpreted in different ways by developers and users.
• In principle, requirements should be both complete and consistent.
• Complete • They should include descriptions of all facilities required.
• Consistent • There should be no conflicts or contradictions in the descriptions of the
system facilities.
• In practice, it is impossible to produce a complete and consistent requirements document.
11
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Non-functional requirements
• are constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
• These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
• Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
12
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Non-functional classification• Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
• Organisational requirements
• Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
13
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 14
Non-functional
requirements
Product
requirements
Organisational
requirements
External
requirements
Portability
requirementsReliability
requirements
Efficiency
requirements
Usability
requirements
Delivery
requirements
Standards
requirements
Implementation
requirements
Legislative
requirements
Ethical
requirements
Interoper-
ability reqs
Safety
requirements
Privacy
requirements
Space
requirements
Performance
requirements
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Non-functional examples• Product requirement
• The user interface for the library system shall be implemented as simple HTML without frames or Java applets.
• Organisational requirement
• The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
• External requirement
• The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
15
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Non-functional req. problems
• Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.
• Non-functional requirements often conflict and interact with other non-functional or functional requirements. These conflicts are common in complex systems.
16
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Example
• A system goal
• The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.
• A verifiable non-functional requirement
• Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
17
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements measures
18
Property Measure
SpeedProcessed transactions/second
User/Event response time Screen refresh time
Size M Bytes Number of ROM chips
Ease of use Training time Number of help frames
ReliabilityMean time to failure
Probability of unavailability Rate of failure occurrence
Availability
RobustnessTime to restart after failure
Percentage of events causing failure Probability of data corruption on failure
Portability Percentage of target dependent statements Number of target systems
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Domain requirements
• Requirements that come from the application domain of the system and that reflect characteristics of that domain.
• Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.
• If domain requirements are not satisfied, the system may be unworkable.
19
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Domain req. examples
• There shall be a standard user interface to all databases which shall be based on the Z39.50 standard.
• Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.
20
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Domain req. problems
• Understandability
• Requirements are expressed in the language of the application domain;
• This is often not understood by software engineers developing the system.
• Implicitness
• Domain specialists understand the area so well that they do not think of making the domain requirements explicit.
21
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
User req. revisited• Should describe functional and non-functional
requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge.
• User requirements are defined using natural language, tables and diagrams as these can be understood by all users.
• Problems with natural language
• Lack of clarity
• Requirements confusion
• Requirements amalgamation22
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Guidelines for writing requirements
• Invent a standard format and use it for all requirements.
• Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements.
• Use text highlighting to identify key parts of the requirement.
• Avoid the use of computer jargon.
23
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
The requirements document
• The requirements document is the official statement of what is required of the system developers.
• Should include both a definition of user requirements and a specification of the system requirements.
• It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.
24
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Users of a requirements document
25
System Customers Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.
Managers
System Engineers
System Maintenance Engineers
System Test Engineers
Use the requirements document toplan a bid for the system and to planthe system development process
Use the requirements to understand whatsystem is to be developed
Use the requirements to develop validation tests for the system
Use the requirements to understand the system and the relationship between its parts.
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
IEEE Requirements standard
• Defines a generic structure for a requirements document that must be instantiated for each specific system.
• Introduction.
• General description.
• Specific requirements.
• Appendices.
• Index.
26
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
SRS document structure• Preface
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index27
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Wrap-up (1)
• Requirements set out what the system should do and define constraints on its operation and implementation.
• Functional requirements set out services the system should provide.
• Non-functional requirements constrain the system being developed or the development process.
• User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.
28
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Wrap-up (2)
• System requirements are intended to communicate the functions that the system should provide.
• A software requirements document is an agreed statement of the system requirements.
• The IEEE standard is a useful starting point for defining more detailed specific requirements standards.
29
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Engineering Processes
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Engineering Processes
• The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.
• However, there are a number of generic activities common to all processes
• Requirements elicitation;
• Requirements analysis;
• Requirements validation;
• Requirements management.31
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 32
Feasibility
study
Requirements
elicitation and
analysis
Requirements
validation
Requirements
specification
Feasibility
report
System
models
User and
system
requirements
Requirements
document
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 33
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 6
Requirements engineering
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Feasibility studies
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Feasibility study
• A feasibility study decides whether or not the proposed system is worthwhile.
• A short focused study that checks
• If the system contributes to organisational objectives;
• If the system can be engineered using current technology and within budget;
• If the system can be integrated with other systems that are used.
35
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 36
Feasibility
study
Requirements
elicitation and
analysis
Requirements
validation
Requirements
specification
Feasibility
report
System
models
User and
system
requirements
Requirements
document
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Elicitation and Discovery
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Elicitation and analysis
• Sometimes called requirements elicitation or requirements discovery.
• Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
• May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
38
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Problems of Requirements Analysis
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may emerge and the business environment change.
39
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
The requirements spiral
40
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 11
The requirements spiral
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Process activities• Requirements discovery • Interacting with stakeholders to discover their
requirements. Domain requirements are also discovered at this stage.
• Requirements classification and organisation • Groups related requirements and organises them into
coherent clusters.
• Prioritisation and negotiation • Prioritising requirements and resolving requirements
conflicts. • Requirements documentation • Requirements are documented and input into the next
round of the spiral.
41
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Discovery
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements discovery
• The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.
• Sources of information include documentation, system stakeholders and the specifications of similar systems.
43
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Viewpoints
• Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints.
• This multi-perspective analysis is important as there is no single correct way to analyse system requirements.
44
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Types of viewpoints
• Interactor viewpoints • People or other systems that interact directly with the system.
In an ATM, the customer’s and the account database are interactor VPs.
• Indirect viewpoints • Stakeholders who do not use the system themselves but who
influence the requirements. In an ATM, management and security
staff are indirect viewpoints.
• Domain viewpoints • Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be standards for inter-bank communications.
45
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Interviewing
• In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.
• There are two types of interview
• Closed interviews where a pre-defined set of questions are answered.
• Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
46
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Interviews in practice• Normally a mix of closed and open-ended
interviewing.
• Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.
• Interviews are not good for understanding domain requirements
• Requirements engineers cannot understand specific domain terminology;
• Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.
47
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Scenarios• Scenarios are real-life examples of how a
system can be used.
• They should include
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario finishes.
48
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Use cases
• Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.
• A set of use cases should describe all possible interactions with the system.
• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.
49
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Social and organisational factors
• Software systems are used in a social and organisational context. This can influence or even dominate the system requirements.
• Social and organisational factors are not a single viewpoint but are influences on all viewpoints.
• Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis.
50
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 51
Feasibility
study
Requirements
elicitation and
analysis
Requirements
validation
Requirements
specification
Feasibility
report
System
models
User and
system
requirements
Requirements
document
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Validation
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements validation
• Concerned with demonstrating that the requirements define the system that the customer really wants.
• Requirements error costs are high so validation is very important
• Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
53
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements checking
• Validity. Does the system provide the functions which best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology?
• Verifiability. Can the requirements be checked?
54
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirement validation techniques
• Requirements reviews
• Systematic manual analysis of the requirements.
• Prototyping
• Using an executable model of the system to check requirements.
• Test-case generation
• Developing tests for requirements to check testability.
55
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Management
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements Management
• Requirements management is the process of managing changing requirements during the requirements engineering process and system development.
• Requirements are inevitably incomplete and inconsistent
• New requirements emerge during the process as business needs change and a better understanding of the system is developed;
• Different viewpoints have different requirements and these are often contradictory.
57
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements management planning
• During the requirements engineering process, you have to plan:
• Requirements identification • Each requirement must be uniquely identified so that it
can be cross-referenced by other requirements and so that it can be used in traceability assessments.
• A change management process • Set of activities that assess impact and cost of changes.
58
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements management planning
• Traceability policies • The amount of information about requirements
relationships that is maintained;
• Source traceability • Links from requirements to stakeholders who proposed these
requirements;
• Requirements traceability • Links between dependent requirements;
• Design traceability • Links from the requirements to the design;
• CASE tool support • The tool support required to help manage requirements
change;59
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Requirements change management
• Should apply to all proposed changes to the requirements.
• Principal stages
• Problem analysis. Discuss requirements problem and propose change;
• Change analysis and costing. Assess effects of change on other requirements;
• Change implementation. Modify requirements document and other documents to reflect change.
60
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Wrap-up (1)
• The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management.
• Requirements elicitation and analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation.
• Systems have multiple stakeholders with different requirements.
61
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Wrap-up (2)
• Social and organisation factors influence system requirements.
• Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability.
• Business changes inevitably lead to changing requirements.
• Requirements management includes planning and change management.
62
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 63
Feasibility
study
Requirements
elicitation and
analysis
Requirements
validation
Requirements
specification
Feasibility
report
System
models
User and
system
requirements
Requirements
document
© Ian Sommerville 2004
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
System Models In RE
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Roadmap
65
• Models
• System models???
• The Unified Modeling Language
• Use Cases for describing requirements
• Behavioural models
• Structural models
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Unified Modeling Language
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
The UML
• The Unified Modeling Language (UML)
• unifies the notations of Booch, Rumbaugh (OMT) and Jacobson (OOSE).
• is approved as a standard by the OMG and has become the de facto modelling language.
• captures knowledge at different abstraction levels
• different diagram types:• class diagrams, object diagrams, use case diagrams, deployment
diagrams, component diagram , state machine diagram, activity diagram, state machine diagram, activity diagram, ....
67
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Ways of using the UML(1)
• As a sketch -> selectivity, exploration
• High level diagrams to help communicate some aspects of a system
• Can be used in 2 directions: • Forward engineering: draw UML diagram before writing code, discuss
and communicate ideas and alternatives about the software that needs to be written
• Reverse engineering: build diagram from existing code, use sketches to explain how some part of the software works
• Sketches are informal and dynamic, on whiteboard or with lightweight drawing tool
• UML diagrams in books are typically sketches
68
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Ways of using the UML(2)
• As a blueprint -> completeness, definition
• Complete detailed design with all design decisions laid out so that a programmer can code from it straightforwardly
• Can also be used in 2 directions
• Requires more sophisticated tools • Forward engineering tools support diagram drawing and back it up with
a repository to hold the information
• Reverse engineering tools read source code, interpret from it into the repository and generate diagrams
• Round-trip tools can do both forward and reverse engineering
69
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Use Cases for Requirements
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Use Cases
• Use cases are a technique for capturing the functional requirements of a system.
• Use cases work by describing the typical interactions between the users of the system and the system itself.
• A use case is
• a set of scenarios tied together by a common user goal.
• No standard way to write the content of a use case, different formats work in different cases.
71
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 72
Staff Contact
Change a client
contact
System or subsystem boundary Actor
Use case Communication association
CampaignManager
«include»Find campaign
Assign staff towork on acampaign
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 73
StaffContact
Recordcompletionof an advert
CampaignManager
Change aclient
contact
Assignindividual staffto work on acampaign
Assign team ofstaff to work on
a campaign
Assign staff towork on acampaign
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 74
Use Case Content Description
• Example of definition of a use case:
• Name: name used to refer to the use case
• Summary: a short description
• Actors: all actors involved
• Preconditions: condition of the system at the start of the use case
• Description: the complete description
• Exceptions: special cases
• Result: condition of the system at the end of the use case
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
System models• System modelling helps the analyst to
understand the functionality of the system and models are used to communicate with customers.
• System models leave out detail.
• Different models present the system from different perspectives • External perspective showing the system’s context or
environment;
• Behavioural perspective showing the behaviour of the system;
• Structural perspective showing the system or data architecture.
76
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Structural Models in RE
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Roadmap Structural Models in RE
• Data models
• Entity-relationship diagram (ERD)
• Data dictionary (DD)
• Object models
• class diagrams
78
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Entity-relationship diagram
• An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes
• Used to describe the logical structure of data processed by the system.
• Widely used in database design. Can readily (after normalization) be implemented using relational databases.
• ERD is not part of UML!!79
Client Campaign
Advert
placesconducted
by
companyAddress
uniqueIDKey Entity
Relation
AttributeMultiplicity
!!!See Database Management!!!
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Data dictionary
• Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included.
• Advantages
• Support name management and avoid duplication;
• Store of organisational knowledge linking analysis, design and implementation.
80
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Data dictionaries entries
81
Name Description Type
Client Agate deals with other companies that it calls clients. Entity
companyName name of the client company Attribute
places A 1:n relationship between Client and Campaign placed by the Client. Relation
Campaign advertising campaign developed by Agata Entity
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Class Diagrams
82
calculateBonus()
assignNewStaffGrade()
getStaffDetails()
staffName
staffNo
staffStartDate
StaffMember
calculateBonus()AdminStaff
calculateBonus()
assignStaffContact()
qualification
CreativeStaff
getClientCampaigns()
addNewCampaigns()
getClient()
assignStaffContact()
companyName
companyAddress
companyEmail
contactName
contactEmail
Client
createCampaign()
getCampaignDetails()
checkCampaignBudget()
getOverheads()
completeCampaign()
title
campaignStartDate
campaignFinishDate
estimatedCost
campaignOverheads
completionDate
Campaign
getCost()
estimatedAdvertCost
actualAdvertCost
Advert
0..1 0..n
staffContact
1
0..*
1
0..*
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Classes and Associations
83
getClientCampaigns()
addNewCampaigns()
getClient()
assignStaffContact()
companyName
companyAddress
companyEmail
contactName
contactEmail
Client
createCampaign()
getCampaignDetails()
checkCampaignBudget()
getOverheads()
completeCampaign()
title
campaignStartDate
campaignFinishDate
estimatedCost
campaignOverheads
completionDate
Campaign1
0..*
places
Class name compartment
Operations compartmentMultiplicities
Association
Attributes compartment
Association name
Direction in which name should be read
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Aggregation and Composition
84
• Special types of association, both sometimes called whole-part
• Aggregation is essentially any whole-part relationship
• Semantics can be very imprecise
• Composition is ‘stronger’:
• Each part may belong to only one whole at a time
• When the whole is destroyed, so are all its parts
Campaign Advert0..*1
Meal Ingredient
11..*
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Inheritance
• Add generalisation structures when:
• Two classes are similar in most details, but differ in some respects
• May differ:
• In behaviour (operations or methods)
• In data (attributes)
• In associations with other classes
85
calculateBonus()
assignNewStaffGrade()
getStaffDetails()
staffName
staffNo
staffStartDate
StaffMember
calculateBonus()AdminStaff
calculateBonus()
assignStaffContact()
qualification
CreativeStaff
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Behavioural Models in RE
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Roadmap Behavioural Models in RE
• Data models
• Data flow diagram (DFD)
• Object models
• State machine
• Sequence diagram
• Activity diagram
87
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Data Flow Diagram
• Data flow diagrams (DFDs) may be used to model the system’s data processing.
• These show the processing steps as data flows through a system.
• DFDs are an intrinsic part of many analysis methods.
• Simple and intuitive notation that customers can understand.
• Show end-to-end processing of data.88
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
DFD Example
89
Blank Campaign
Form
Complete
Campaign
Form
Validate
Campaign
Form
Record
Campaign Form
Send to Creative
Director
Adjust available
budget
Campaign
execution details
Campaigns
Budgets
Completed
Campaign form
Signed campaign
form
Campaign details
budget
Signed campaign
form
Signed campaign
form
InputFunction
Output
Data flow
File/Database
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Data Flow Diagrams
• DFDs model the system from a functional perspective.
• Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system.
• Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment.
90
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
State Machine Models
• These model the behaviour of the system in response to external and internal events.
• They show the system’s responses to stimuli.
• State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.
• State machine diagrams are an integral part of the UML.
91
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
UML State machine
92
Commissioned
Authorized (authorizationCode)[contract signed]/setCampaignActive
/assignManager; assignStaff
Advert Preparation
Completed
Paid
campaignCompleted/prepareFinalStatement
paymentReceived (payment)[paymentDue - payment > zero]
paymentReceived (payment)[paymentDue - payment = zero]
archiveCampaign/unassignStaff; unassignManager
paymentReceived (payment)[paymentDue - payment < zero]/generateRefund
Running Adverts SchedulingconfirmSchedule
extendCampaign/modifyBudget
advertsApproved/authorize
Active
sm Campaign Version 2
Start state
Trigger signature [Guard]/Activity
Transition
Superstate
End state
State
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Transitions in UML SM
93
• Trigger-signature [Guard] / Activity
• Trigger-signature: an event whose reception by the object in the source state makes the transition legible to fire, providing the guard condition is satisfied.
• Guard: a boolean expression, evaluated when the transition is triggered by the reception of the event trigger; if the expression evaluates True, the transition is legible to fire, if the expression evaluates to False, the transition does not fire and if there is no other transition that could be triggered by the same event, the event is lost.
• Activity: some behaviour executed during the transition
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Concurrent States
94
Advert Preparation
Running Adverts SchedulingconfirmSchedule
extendCampaign/modify Budget
advertsApproved/authorize
Active
Survey
Evaluation
surveyComplete
runSurvey
Running
Monitoring
campaignCompleted/prepareFinalStatement
Fork
Join
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Sequence Diagram
• Shows an interaction between lifelines (e.g. objects) arranged in a time sequence.
• Can be drawn at different levels of detail and to meet different purposes at several stages in the development life cycle.
• Typically used to represent the detailed object interaction that occurs for one use case or for one operation.
95
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Sequence Diagrams
96
Campaign
Manager
:Client :Campaign :Advert
newAd:Advert
getName
listCampaigns
listAdverts
addNewAdvert
new
sd Add a new Advert to a campaign
loop
loop
getAdvertDetails
getCampaignDetails
[For all client's campaigns]
[For all campaign's adverts]
Interaction operator
Interaction Constraint Combined
Fragment(loop)
Lifeline Activation
Synchronousmessage
ObjectCreation
Result
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
UML Activity Diagrams
• are used for the following purposes
• to model business activities
• to model a process
• to model a function represented by a use case (e.g., during requirements elaboration)
97
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Activity Diagram Examples
98
Initial Node
Action
Control Flow
MergeNode
Final Node
Fork
Join
Add a new
client
Assign staff
contact
Add new
campaign
Add a new
client
Assign staff
contact
Add new
campaign
[Campaign to add]
[No campaign
to add]
Guard
DecisionNode
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
From Requirements to Models
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 100
Campaign Manager
Add a new
advert to a
campaign
1
2
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 101
CRC cards• Class - Responsibility - Collaboration
• focus on behaviour, the idea is that you should be able to take any class and summarize it with a handful of responsibilities.
• Responsibility: a short sentence that summarizes something that an object should do:
• an action the object performs,
• some knowledge the object maintains, or
• some important decisions the object makes.
• Collaboration: the other classes that this class needs to work with. This gives you some idea of the links between classes—still at a high level.
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008 102
Class Name Client
Responsibilities Collaborations
Provide client information.
Campaign
Class Name Campaign
Responsibilities Collaborations
Provide campaign information.
Provide list of adverts.Add a new advert.
Advert
Advert
Class Name Advert
Responsibilities Collaborations
Provide advert details.
Construct adverts.
Provide list of campaigns.
© Bennett, McRobb and Farmer 2005
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
References
• The previous slides highly depend on:
• [Sommerville] Ian Sommerville. Software Engineering. Eighth Edition. 2007. ISBN: 9780321313799
• [Benett et al.] Simon Benett, Steve McRobb and Ray Farmer. Object-Oriented Systems Analysis and Design. (using UML) Third Edition.
103
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
References
• UML: http://www.uml.org/
• Pierre-Alain Muller, Nathalie Gaertner. Modélisation objet avec UML. Groupe Eyerolles. ISBN 2212113978
104
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Model Consistency
• Consistency checks are an important task in the preparation of a complete set of models.
• Highlights omissions and errors, and encourages the clarification of any ambiguity or incompleteness in the requirements.
105
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Consistency Checking• Every event should appear as an incoming message
for the appropriate object on an interaction diagram(s).
• Every action should correspond to the execution of an operation on the appropriate class, and perhaps also to the despatch of a message to another object.
• Every event should correspond to an operation on the appropriate class (but note that not all operations correspond to events).
• Every outgoing message sent from a state machine must correspond to an operation on another class.
106
Ragnhild Van Der Straeten - ULB - Génie logiciel et gestion de projets - 2007/2008
Consistency Checking
• more difficult ones exist:• each call sequence of the superclass SM should be contained in the set of
call sequences of the SM of the subclass;
• the ordered collection of messages received by an object of the superclass should be contained in the ordered collection of messages received by an object of the subclass;
• the ordered collection of messages received by an object of the superclass in a sequence diagram, should exist as a call sequence of the PSM for the subclass.
• Interested?? Check http://ssel.vub.ac.be/thesis for information on apprenticeship and theses
107