SEOC 2004-2011
-
Upload
massimo-felici -
Category
Documents
-
view
575 -
download
1
Transcript of SEOC 2004-2011
Software Engineering with Objects andComponents
Massimo Felici
Massimo Felici Software Engineering with Objects and Components c©2004-2011
Course Organisation 1/4 1
Course Organisation
• SEOC course webpage
http://www.inf.ed.ac.uk/teaching/courses/seoc/
• Mailing List
Massimo Felici Software Engineering with Objects and Components c©2004-2011
Course Organisation 2/4 2
Course Resources
• Course Textbook
UML, Second Edition, by Simon Bennet, John Skelton and Ken Lunn,Schaum’s Outline Series, McGraw-Hill, 2005
• Course Resources
Lecture Notes and References
• Software
NetBeans or Eclipse + UML plugin
Massimo Felici Software Engineering with Objects and Components c©2004-2011
Slide 2: NetBeans or Eclipse?
• The management/configuration of eclipse plugins seems to be a bit more complicated. In
particular, the UML2 plugin sitting on top of the EMF (Eclipse Modeling framework) is
constantly exposed to the eclipse evolution. Moreover, the code generation functionality is
more complicated, because it involves subsequent steps (UML models→ EMF→ Java), and
generates additional Java code that is misleading and difficult to deal with.
• NetBeans, although it seems to be slower than eclipse in terms of performance, seems it is
keeping the plugins management a bit more under control than eclipse. It supports basic UML
models, although not all of them. It also supports various plugins like Visual Paradigm and
BlueJ. The former is quite powerful, even the community edition (for non commercial use).
The latter is the one adopted by the Introduction to Java Programming course. The BlueJ
plugin is meant to support the transition from BlueJ projects to more advanced ones with
NetBeans.
• It should be quite useful the link between NetBeans and BuleJ. This should help who take
both courses SEOC and IJP. Moreover, NetBeans supports also the basic Design Patterns,
which are introduced in the course, and it comes also with Junit.
Course Organisation 3/4 3
Tutorials
• Tutorials begin in week 3
• Frequency once a week ; Maximum 12 people per tutorial group
Massimo Felici Software Engineering with Objects and Components c©2004-2011
Course Organisation 4/4 4
Coursework
• Group Coursework
in small teams (approx 3-4 people)
two deliverables equally weighted
• Coursework Deadlines
1st deliverable: Friday, 2pm, 28th October 2011 (week 6)
2nd deliverable: Friday, 2pm, 25th November 2011 (week 10)
• Assessment
25% coursework; 75% exam
Massimo Felici Software Engineering with Objects and Components c©2004-2011
On Software Engineering
Massimo Felici
Massimo Felici On Software Engineering c©2004-2011
1
What is Software Engineering
Software Engineering is an engineering discipline that is concerned with allaspects of software production from the early stages of system specification tomaintaining the system after it has gone into use.
Massimo Felici On Software Engineering c©2004-2011
Slide 1: What is Software Engineering
This lecture provides a very brief introduction to Software Engineering. The SEOCcourse focuses on engineering software systems using Objects and Components.The main learning objectives of the course involve the acquisition of softwareengineering knowledge and ability to design, assess and implement object-orientedsystems. The course uses UML as modelling language. The course organisationembeds some general software engineering principles and practices.
Required Readings
• B. Meyer. Software Engineering in the Academy. IEEE Computer, May 2001,pp. 28-35. It provides a discussion on software engineering education.
Slide 1: What is Software Engineering
Suggested Readings
• For an introduction to various aspects of Software Engineering refer to I.Sommerville. Software Engineering, Eighth Edition, Addison-Wesley 2007. Inparticular, Chapter 1 for a general account of Software Engineering.
• SWEBOK - Guide to the Software Engineering Body of Knowledge. 2004Version, IEEE.
2
Some Aspects of Software Engineering
• Software Processes
• Software Process Models
• Software Engineering Methods
• Costs
• Software Attributes
• Tools
• Professional and Ethical Responsibilities
Massimo Felici On Software Engineering c©2004-2011
Slide 2: Some Aspects of Software Engineering
Software Engineering is concerned with all aspects of software production. Themain objective is to support software production in order to deliver software thatis “fit for purpose”, e.g., good enough (functionally, non-functionally), meetsconstraints (e.g., time and financial) of the environment, law, ethics and workpractices.
A Software Process is the set of activities and associated results (e.g., softwarespecification, software development, software validation and software evolution)that produce a software product.
A Software Process Model is an overview of the software activities and resultsorganisation.
Software Engineering processes (e.g., waterfall, spiral, etc.) arrange (deployeffort) activities differently. The SEOC organisation, to a certain extent, embedssome basic principles underlying different software engineering processes.
Slide 2: Some Aspects of Software Engineering
Essential software activities are:
• Software Requirements: gaining an accurate idea of what the users of thesystem want it to do.
• Software Design: the design of a system to meet the requirements.
• Software Construction: the realisation of the design as a program.
• Software Testing: the process of checking the code meets the design.
• Software Configuration, Operation and Maintenance: major cost in the lifetimeof systems.
Suggested Readings
• Chapter 4 on Software Processes in Summerville’s book.
3
Why Software Fails?
• Complex causes (interactions) trigger software failures
• Software fails in context
• Some issues related to software engineering
– Misunderstood requirements– Design issues– Mistakes in specification, design or implementation– Operational issues
• Faults, Errors and Failures
Massimo Felici On Software Engineering c©2004-2011
Slide 3: Why Software Fails?
Unfortunately, software still fails too often. Software fails in complex manners.Although the course stresses the importance of software designs and models, itis often difficult to understand how software engineering aspects (e.g., design,implementation, etc.) relate to or address software failures. Software failures mayhave dependability (e.g., safety, reliability, etc.) as well as financial implications.
Required Readings
• R.N. Charette. Why Software Fails. IEEE Spectrum, pp. 42-49, September2005.
Suggested Readings
• Chapter 3 on Critical Systems in Sommerville’s book.
4
Faults, Errors and Failures
• Fault - The adjudged or hypothesized cause of a an error is called a fault. Afault is active when it causes an error, otherwise it is dormant.
• Error - The deviation from a correct service state is called an error. An erroris the part of the total state of the system that may lead to its subsequentservice failure.
• Failure - A failure is an event that occurs when the delivered service deviatesfrom correct service.
Warnings: different understandings of faults, errors and failures.
Massimo Felici On Software Engineering c©2004-2011
Slide 4: Faults, Errors and Failures
An important aspect is to understand how faults, errors and failures relate eachother. Research and practice in engineering safety-critical systems emphasizethe underlying mechanisms of software failures. Note that understanding theseconcepts (i.e., faults, errors and failures) in practice often requires expertise withinspecific application domains, which might have different interpretations of them.
Suggested Readings
• A. Avizienis, J.-C. Laprie, B. Randell and C. Landwehr. Basic Conceptsand Taxonomy of Dependable and Secure Computing. IEEE Transactions onDependable and Secure Computing 1(1):11-33, January-March 2004.
Software Failures 1 5
Some “Famous” Software Failures
• Patriot Missile failure
– Inaccurate calculation of the time since boot due to computer arithmeticerrors Coding errors may effect overall software system behaviour
• The Ariane 5 Launcher failure
– The complete loss of guidance and altitude information 37 seconds afterstart of the main engine ignition sequence
– The loss of information was due to specification and design errors in thesoftware of the inertial reference system
– The software that failed was reused from the Ariane 4 launch vehicle. Thecomputation that resulted in overflow was not used by Ariane 5
Massimo Felici On Software Engineering c©2004-2011
Software Failures 2 6
Some “Famous” Software Failures
• The London Ambulance fiasco
• Therac 25 and other medical device failures
– (Software) Reliability is different than (System) Safety
Massimo Felici On Software Engineering c©2004-2011
Slide 6: Some “Famous” Software Failures
Required Readings
• B. Nuseibeh. Ariane 5: Who Dunnit? IEEE Software, pp. 15-16, May/June1997.
• J.-M. Jezequel, B. Meyer. Design by Contract: The Lessons of Ariane. IEEEComputer, pp. 129-130, January 1997.
• M. Grottke, K.S. Trivedi. Fighting Bugs: Remove, Retry, Replicate, andRejuvenate. IEEE Computer, pp. 107-109, February 2007.
Slide 6: Some “Famous” Software Failures
Suggested Readings
• N.G. Leveson, C.S. Turner. An investigation of the Therac-25 accidents. IEEEComputer 26(7): 18-41, Jul 1993.
• D.R. Wallace, D.R. Kuhn. Lessons from 342 Medical Device Failures. InProceedings of HASE 1999, pp. 123-131.
The Patriot Missile Failure 1 7
The Patriot Missile Failure
Accident Scenario: On February 25, 1991, during the Gulf War, an AmericanPatriot Missile battery in Dharan, Saudi Arabia, failed to track and intercept anincoming Iraqi Scud missile. The Scud struck an American Army barracks, killing28 soldiers and injuring around 100 other people.
Massimo Felici On Software Engineering c©2004-2011
Slide 7: The Patriot Missile Failure
A report of the General Accounting office, GAO/IMTEC-92-26, entitled PatriotMissile Defense: Software Problem Led to System Failure at Dhahran, SaudiArabia, reported on the cause of the failure.
The Patriot Missile Failure 2 8
The Patriot Missile Failure
• Fault - Inaccurate calculation of the time since boot due to computer arithmeticerrors.
• Error - The small chopping error, when multiplied by the large number givingthe time in tenths of a second, lead to a significant error of 0.34 seconds.
• Failure - A Scud travels at about 1,676 meters per second, and so travelsmore than 500 meters in this time. This was far enough that the incomingScud was outside the range gate that the Patriot tracked.
Massimo Felici On Software Engineering c©2004-2011
Slide 8: The Patriot Missile Failure
Fault - The time in tenths of second as measured by the system’s internal clockwas multiplied by 1/10 to produce the time in seconds. This calculation wasperformed using a 24 bit fixed point register. In particular, the value 1/10, whichhas a non-terminating binary expansion, was chopped at 24 bits after the radixpoint.
Slide 8: The Patriot Missile Failure
Error - Indeed, the Patriot battery had been up around 100 hours, and an easycalculation shows that the resulting time error due to the magnified choppingerror was about 0.34 seconds. The binary expansion of 1/10 is
0.0001100110011001100110011001100...
The 24 bit register in the Patriot stored instead
0.00011001100110011001100
introducing an error of
0.0000000000000000000000011001100... binary, or about 0.000000095 decimal.Multiplying by the number of tenths of a second in 100 hours gives
0.000000095× 100× 60× 60× 10 = 0.34.
Ironically, the fact that the bad time calculation had been improved in some partsof the code, but not all, contributed to the problem, since it meant that theinaccuracies did not cancel.
The Patriot Missile Failure 3 9
The Patriot Missile Failure
• Identifying coding errors is very hard
seemingly insignificant errors result in major changes in behaviour
• Original fix suggested a change in procedures
reboot every 30 hours impractical in operation
• Patriot is atypical
coding bugs rarely cause accidents alone
• Maintenance failure failure of coding standards and traceability
Massimo Felici On Software Engineering c©2004-2011
UML 1 10
Supporting Software Engineering Practices
• Provides a range of graphical notations that capture various aspects of theengineering process
• Provides a common notation for various different facets of systems
• Provides the basis for a range of consistency checks, validation and verificationprocedures
• Provides a common set of languages and notations that are the basis forcreating tools
Massimo Felici On Software Engineering c©2004-2011
Slide 10: Supporting Software Engineering Practices
Required Readings UML course textbook
• Chapter 1 on the Introduction to the Case Studies.
• Chapter 2 on the Background to UML.
UML 2 11
Some UML Diagrams
• Use Case Diagrams
• Class Diagrams
• Interaction Diagrams
Sequence and Communication Diagrams
• Activity Diagrams
• State Machines
Massimo Felici On Software Engineering c©2004-2011
Slide 11: Some UML Diagrams
• Use Case Diagrams
Used to support requirements capture and analysis; show the actors involvementin system activities
• Class Diagrams
Capture the static structure of systems; associations between classes
• Interaction Diagrams
Capture how objects interact to achieve a goal
Slide 11: Some UML Diagrams
• Activity Diagrams
Capture the workflow in a situation
• State Machines:
Capture state change in objects of the system
• Other Diagrams: Component and Deployment Diagrams
12
Required Readings
• UML course textbook
– Chapter 1 on the Introduction to the Case Studies.
– Chapter 2 on the Background to UML
• B. Meyer. Software Engineering in the Academy. IEEE Computer, May 2001, pp. 28-35.
• R.N. Charette. Why Software Fails. IEEE Spectrum, pp. 42-49, September 2005.
• B. Nuseibeh. Ariane 5: Who Dunnit? IEEE Software, pp. 15-16, May/June 1997.
• J.-M. Jezequel, B. Meyer. Design by Contract: The Lessons of Ariane. IEEE Computer, pp.
129-130, January 1997.
• M. Grottke, K.S. Trivedi. Fighting Bugs: Remove, Retry, Replicate, and Rejuvenate. IEEE
Computer, pp. 107-109, February 2007.
Massimo Felici On Software Engineering c©2004-2011
13
Suggested Readings
• I. Sommerville. Software Engineering, Eighth Edition, Addison-Wesley 2007.
– Chapter 1 for a general account of Software Engineering
– Chapter 3 on Critical Systems
– Chapter 4 on Software Processes
• SWEBOK – Guide to the Software Engineering Body of Knowledge. 2004 Version, IEEE.
• A. Avizienis, J.-C. Laprie, B. Randell and C. Landwehr. Basic Concepts and Taxonomy of
Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing
1(1):11-33, January-March 2004.
• N.G. Leveson, C.S. Turner. An investigation of the Therac-25 accidents. IEEE Computer
26(7): 18-41, Jul 1993.
• D.R. Wallace, D.R. Kuhn. Lessons from 342 Medical Device Failures. In Proceedings of HASE
1999, pp. 123-131.
Massimo Felici On Software Engineering c©2004-2011
14
Summary
• SEOC organisation
• An introduction to Software Engineering
• Why Software Fails
• Faults, Errors and Failures
• Examples of Software Failures
• An Outline of some UML diagrams
• Required Readings and Suggested Readings
Massimo Felici On Software Engineering c©2004-2011
Gathering and Organising System Requirements
Massimo Felici
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
1
10 Top Reasons for Not Doing Requirements
1. We don’t need requirements, we’re using objects, java, web...2. The users don’t know what they want3. We already know what the users want4. Who cares what the users want?5. We don’t have time to do requirements6. It’s too hard to do requirements7. My boss frowns when I write requirements8. The problem is too complex to write requirements9. It’s easier to change the system later than to do the requirements up front
10. We have already started writing code, and we don’t want to spoil it
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
VolBank - Volunteer Bank 1 2
VolBank: Requirements
1. To develop a system that will handle the registration of volunteers and thedepositing of their time.
2. To handle recording of opportunities for voluntary activity.
3. To match volunteers with people or organisations that need their skills.
4. To generate reports and statistics on volunteers, opportunities an timedeposited.
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
3
Requirements Engineering Activities
Requirements
Elicitation
Requirements
Analysis and
Negotiation
Requirements
Documentation
Requirements
Validation
Requirements
Document
System
Specification
Agreed
Requirements
User needs
Domain Information
Existing system information
Regulations
Standards
Etc.
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Slide 3: Requirements Engineering Activities
Main activities involved in Software Requirements engineering:
Elicitation: Identify sources; Elicit requirements
Analysis and Negotiation: Classify requirements; Model; Top-levelarchitecture; Allocate requirements to components; Negotiate requirements
Documentation: Requirements Definition Doc; Software RequirementsSpecification; Document Standards; Document Quality
Validation: Reviews; Prototypes; Modelling; Test definition
Management: Traceability; Attributes; Change/Evolution
The pattern, sequence and interaction of these activities is orchestrated by aRequirements Engineering Process.
Slide 3: Requirements Engineering Activities
Required Readings
• I. Sommerville. Integrated Requirements Engineering: A Tutorial. IEEESoftware, January/February 2005, pp. 16-23.
Suggested Readings
• I. Sommerville, P. Sawyer. Requirements Engineering: A Good Practice Guide.John Wiley & Sons, 1997.
• G. Kotonya, I. Sommerville. Requirements Engineering: Processes andtechniques. John Wiley & Sons, 1998.
• I. Sommerville. Software Engineering, Eighth Edition, Addison-Wesley 2007.– Chapter 6 on Software Requirements.– Chapter 7 on Requirements Engineering Processes.
4
Requirements Elicitation Activities
• Application domain understandingApplication domain knowledge is knowledge of the general area where thesystem is applied
• Problem understandingThe details of the specific customer problem where the system will be appliedmust be understood
• Business understandingYou must understand how systems interact and contribute to overall businessgoals
• Understanding the needs and constraints of system stakeholdersYou must understand, in detail, the specific needs of people who require systemsupport in their work
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Slide 4: Requirements Elicitation Techniques
• Interviews with stakeholdersClose/Open (Structured/Unstructured), Facilitated Meetings (e.g.,professional group work)
• ScenariosElicit the ‘usual’ flow of work; Are stories which explain how a system mightbe used; Expose possible system interactions and reveal system facilities whichmay be required
• PrototypesMock-up using paper, diagrams or software
• ObservationsObserving ‘real world’ work
Some requirements elicitation techniques find grounds in Ethnography - atechnique from the social sciences. Note that actual work processes oftendiffer from formal prescribed processes.
VolBank - Volunteer Bank 2 5
VolBank: Elicitation
• Goals (why the system is being developed)An high level goal is to increase the amount of volunteer effort utilised byneedy individuals and organisationsPossible requirements in measurement and monitoring
• Domain KnowledgeSome specific requirements, e.g., Safety and Security
• StakeholdersVolunteers, organisations, system administrators, needy people, operator,maintenance, manager
• Operational EnvironmentProbably constrained by software and hardware in the office
• Organisational EnvironmentLegal issues of keeping personal data, safety issues in ‘matching’
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
VolBank - Volunteer Bank 3 6
VolBank: Examples of Requirements
• Volunteer identifies:
1. The need for security/assurance in contacting organisations
• Management identifies:
2. The number of hours volunteered per month above a given baseline as thekey metric
• Operator identifies:
3. The need to change details when people move home4. The need to manage disputes when a volunteer is unreliable, or does bad
work
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
7
Requirements Analysis
• Discovers problems, incompleteness and inconsistencies in the elicitedrequirements
• A problem checklist may be used to support analysis
• A Problem Checklist
– Premature design– Combined requirements– Unnecessary requirements– Requirements ambiguity– Requirements realism– Requirements testability
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Slide 7: Requirements Analysis
Requirements Analysis involves: Classification, Conceptual Modeling,Architectural Design and Requirements Allocation and Requirements Negotiation.
Requirements Analysis deals with large volume of requirements information,detects and resolves conflicts, scopes the system and defines interfaces withthe environment, translates system requirements into software requirements andprovides feedback to the stakeholders (in order to resolve conflicts through thenegotiation process).
A Problem Checklist: Premature design, Combined requirements, Unnecessaryrequirements, Use of non-standard hardware, Conformance with business goals,Requirements ambiguity, Requirements realism, Requirements testability.
Definitions 8
Functional and Non-functional Requirements
Functional Requirements: “These are statements of services the systemshould provide, how the system should react to particular inputs and how thesystem should behave in particular situations. In some cases, the functionalrequirements may also explicitly state what the system should not do.”
Non-functional Requirements: “These are constraints on the services. Theyinclude timing constraints, constraints on the development process andstandards. Non-functional requirements often apply to system as a whole.They do not usualy just apply to individual system features or services.”
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Slide 8: Examples of Functional Requirements
Examples of functional requirements for a university library system used bystudents and faculty to order books and documents from other libraries.
1. The user shall be able to search either all of the initial set of databases orselect a subset from it.
2. The system shall provide appropriate viewers for the user to read documentsin the document store.
3. Every order shall be allocated a unique identifier, which the user shall be ableto copy to the accounts permanent storage area.
Slide 8: Non-functional Requirements
• Non-functional requirements (e.g., safety, security, usability, reliability, etc.)define the overall qualities or attributes of the resulting system
• Constraints on the product being developed and the development process
• Warnings: unclear distinction between non-functional andfunctional requirements
Suggested Readings
• J. Boegh, S. De Panfilis, B. Kitchenham, A. Pasquini. A Method for SoftwareQuality Planning, Control, and Evaluation. IEEE Software, March/April 1999,pp. 69-77.
Slide 8: Metrics for Specifying Non-functional Requirements
Property Measure
Speed Processed transactions/secondUser/Event response timeScreen refresh time
Size K bytesNumber of RAM chipsLines of Code (LOC)
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target-dependent statementsNumber of target systems
VolBank - Volunteer Bank 4 9
VolBank: Analysis and Classification
• Functional Requirements
– The system allows a volunteer to be added to the register of volunteers.The following data will be recorded:...
• Non-functional Requirements
– The system ensures confidentiality of personal data and will not release itto a third party
– The system ensures the safety of all participants
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
VolBank - Volunteer Bank 5 10
VolBank: A Failed Match Scenario
• Goal: to handle failure of a match• Context: the volunteer and organisation have been matched and a date for a
preliminary meeting established• Resources: time for volunteer and organisation• Actors: volunteer, operator, organisation• Episodes:
– The volunteer arrives sees the job to be done and decides (s)he cannot do it– Organisation contacts operator to cancel the match and reorganise
• Exceptions: volunteer fails to show up
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
11
Other Requirements Activities
• Constructing Specifications
System requirements definition: customer facing, at system level
Software Requirements Specification: developer facing, at software level
• Requirements Validation
define the acceptance test with stakeholders
• Requirements Management
Manage requirements and maintain traceability
Requirements change because the environment changes and there is a need toevolve
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Slide 11: Other Requirements Activities
There are four main types of traceability links with respect to their processrelationships to requirements:
Forward from requirements. Responsibility for requirements achievement mustbe assigned to system components, such that accountability is established andthe impact of requirements change can be evaluated.
Backward to requirements. Compliance of the system with requirements mustbe verified, and gold-plating (designs for which no requirements exist) must beavoided.
Forward to requirements. Changes in stakeholder needs, as well as in technicalassumptions, may require a radical reassessment of requirements relevance.
Backward from requirements. The contribution structures underlyingrequirements are crucial in validating requirements, especially in highly politicalsettings.
Slide 11: Other Requirements Activities
Suggested Readings
• M. Jarke. Requirements Tracing. Communications of the ACM, Vol. 41, No.12, December 1998.
VolBank - Volunteer Bank 6 12
VolBank: Conceptual Modelling
• Process of requirements engineering is usually guided by a requirements method
• Requirement methods are systematic ways of producing system models
• System models important bridges between the analysis and the design process
• Begin to identify classes of object and their associations: volunteer, contactdetails, match, skills, organisation, needs, etc.
• Start to consider some high level model of the overall workflow for the processusing modelling tools
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Software Requirements Specification (SRS) 13
How to organise requirements“The software requirements document (sometimes called the softwarerequirements specification or SRS) is the official statement of what the systemdevelopers should implement. It should include both the user requirements for asystem and a detailed specification of the system requirements. In some cases,the user and system requirements may be integrated into a single description.In other cases, the user requirements are defined in an introduction to thesystem requirements specification. If there are a large number of requirements,the detailed system requirements may be presented in a separate document.”
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
A basic structure 14
Software Requirements Specification (SRS)1. PROJECT DRIVERS
• The Purpose of the Product• Scope• Stakeholders
2. PROJECT CONSTRAINTS• Development Environment• Deadlines
3. FUNCTIONAL REQUIREMENTSfunctional requirement 1:
...functional requirement m:
4. NON-FUNCTIONAL REQUIREMENTS (e.g., Reliability, Usability, Security, Maintainability, etc.)non-functional requirement 1:
...non-functional requirement n:
5. PROJECT ISSUES• Open Issues• Evolution (e.g., Requirements changes, Future Requirements, etc.)
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Slide 14: Software Requirements Specification (SRS)
You may want to use the VOLERE template or the IEEE Std 830-1998(tailored for your purposes) or any similar SRS template as support for yourpractical work. The VOLERE requirements shell and the IEEE standardprovide guidance for writing requirements.
Required Readings
• IEEE Recommended Practice for Software Requirements Specifications, IEEEStd 830-1998.
Suggested Readings
• S. Robertson, J. Robertson. Mastering the Requirements Process. Addison-Wesley, 1999.
VolBank - Volunteer Bank 7 15
VolBank: Design and Allocation
• How do we allocate requirements?– The system shall ensure the safety of all participants?
• Further analysis to identify principal threats:– Safety of the volunteer from hazards at the work site– Safety of the organisations from hazards of poor or inadequate work– Safety of people from volunteers with behavioural problems– ...
• Design might allow us to allocate:1. to an information sheet2. to a rating component and procedures on allocating work3. to external police register4. ...
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
VolBank - Volunteer Bank 8 16
VolBank: Negotiation
• Safety and Privacy requirements
– may be inconsistent or conflicting– need to modify one or both– Privacy: only authorised releases for safety checks will be permitted and
there is a procedure for feeding back to the individual if a check fails.
• Some requirements may be achievable but only at great effort
– Attempt to downscale– Prioritise– It may be too much effort to implement a fault reporting system in the first
release of the system
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
17
Required Readings
• I. Sommerville. Integrated Requirements Engineering: A Tutorial. IEEESoftware, January/February 2005, pp. 16-23.
• IEEE Recommended Practice for Software Requirements Specifications, IEEEStd 830-1998.
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
18
Suggested Readings
• I. Sommerville, P. Sawyer. Requirements Engineering: A Good Practice Guide.John Wiley & Sons, 1997.
• G. Kotonya, I. Sommerville. Requirements Engineering: Processes andtechniques. John Wiley & Sons, 1998.
• I. Sommerville. Software Engineering, Eighth Edition, Addison-Wesley 2007.– Chapter 6 on Software Requirements.– Chapter 7 on Requirements Engineering Processes.
• M. Jarke. Requirements Tracing. Communications of the ACM, Vol. 41, No.12, December 1998.
• S. Robertson, J. Robertson. Mastering the Requirements Process. Addison-Wesley, 1999.
• J. Boegh, S. De Panfilis, B. Kitchenham, A. Pasquini. A Method for SoftwareQuality Planning, Control, and Evaluation. IEEE Software, 16(2):69-77, 1999.
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
19
Summary
• Requirements Engineering
Involves diverse activities
Supports the construction of quality systems
• Issues are very wide ranging
Poor requirements lead to very poor systems
Negotiating agreement between all the stakeholders is hard
• It may be possible to use a more formal notation to capture some aspects ofthe system
Massimo Felici Gathering and Organising System Requirements c© 2004-2011
Use Cases
Massimo Felici
Massimo Felici Use Cases c© 2004–2011
1
Use Cases
• Support requirements engineering activities and the requirement process
• Capture what a system is supposed to do, i.e., systems functionalrequirements
• Describe sequences of actions a system performs that yield an observableresult of value to a particular actor
• Model actions of the system at its external interface
• Capture how the system coordinates human actions
Massimo Felici Use Cases c© 2004–2011
2
The Benefits of Use Cases
• Relatively easy to write and easy to read• Comprehensible by users• Engage the users in the requirements process• Force developers to think through the design of a system from a user viewpoint• Identify a context for the requirements of the system• Critical tool in the design, implementation, analysis and testing process• Rapid change allows exploratory approach• Serve as inputs to the user documentation
Massimo Felici Use Cases c© 2004–2011
3
Use Cases: Strengths and Weaknesses
• Strengths
– Capture different actors views of the system– Capture some structures in requirements– Are comprehensible by naıve users
• Weaknesses
– Lack of non-functional requirements– Lack of what the system shall not do
Massimo Felici Use Cases c© 2004–2011
4
Use Cases at a Glance
Generalization
Massimo Felici Use Cases c© 2004–2011
Warnings and Hints 5
Actors and Use Cases
• Finding nonhuman actors
– Incorporating other systems (e.g., databases)– Ignoring internal components– Input/Output Devices
• Roles of the Actors
• Naming the Actors
Massimo Felici Use Cases c© 2004–2011
Example 1 6
Actors and Use Cases
Massimo Felici Use Cases c© 2004–2011
Example 2 7
Actors and Use Cases
Massimo Felici Use Cases c© 2004–2011
Sample Questions 8
Finding ActorsThe actors can be identified by answering a number of questions:
• Who will use the main functionality of the system?
• Who will need support from the system to do their daily tasks?
• Who will need to maintain and administer the system, and keep it working?
• Which hardware devises does the system need to handle?
• With which other systems does the system need to interact?
• Who or what has an interest in the results (the value) that system produces?
Massimo Felici Use Cases c© 2004–2011
Example 3 9
Generalizations between Actors
Massimo Felici Use Cases c© 2004–2011
Sample Questions 10
Finding Use CasesFor each identified actor, ask the following questions:
• Which functions does the actor require from the system? What does the actorneed to do?
• Does the actor need to read, create, destroy, modify, or store some kind ofinformation in the system?
• Does the actor have to be notified about events in the system, or does theactor need to notify the system about something? What do those eventsrepresent in terms of functionality?
• Could the actor’s daily work be simplified or made more efficient bu addingnew functions to the system?
Massimo Felici Use Cases c© 2004–2011
Example 4 11
Generalizations between Use CasesPayment, for instance, is a generalization of Payment by credit cards and paymentby cash
Massimo Felici Use Cases c© 2004–2011
Example 5 12
<<include>> Relationship
Massimo Felici Use Cases c© 2004–2011
Example 6 13
<<extend>> Relationship
Massimo Felici Use Cases c© 2004–2011
Example 7 14
<<extend>> Relationship
Massimo Felici Use Cases c© 2004–2011
Example 8 15
System Boundaries
Massimo Felici Use Cases c© 2004–2011
16
Use Case Descriptions
• A use case description complements each use case in the diagram• Identify use case information
Warnings: avoid to specify design information• A use case main course (of actions) is a generic sequence of actions undertaken
in using the system– Identify pre and post conditions– Identify alternate courses
• Provide generic test scenarios for the full system• Templates capture/structure use case information• Some types of information are, e.g.: actors, related requirements, preconditions,
successful/failed end conditions
Massimo Felici Use Cases c© 2004–2011
Description Example 1 17
Use Case DescriptionsUse Case name: Register for Courses
Description: This use cases allows students to register for informatics courses.The student uses the Informatics Course Registration System, an online system,for selecting the courses to attend for the forthcoming semester.
Main course:
1. This use case starts when a student visits the system web page1.1 The system provides the list of available courses in the forthcoming
semester2. The student identifies the courses and select them3. The student confirm the selection, which is then recorded
Massimo Felici Use Cases c© 2004–2011
Description Example 2 18
Use Case DescriptionsUse Case name: request an appointment with a GP (General Practitioner).
Description: An system allows patients to request appointments with GPs.
Main course:
1. A patient requests appointment to the system2. The system queries a scheduler for available GPs and times3. The system responds with GPs and times4. The system negotiates with Patient on suitable GP/time5. The system confirms GP/time with the Scheduler6. The scheduler responds with confirmation of appointment (e.g., booking
number)7. The system communicates confirmation to Patient
Massimo Felici Use Cases c© 2004–2011
19
A Basic Use Case TemplateUse Case [number ]] the name is the goal as a short active verb phrase
Goal in Context a longer statement of the goal, if needed
Preconditions what we expect is already the state of the world
Success End Condition the state of the world upon successful completion
Failed End Condition the state of the world if goal abandoned
Primary Actor a role name or description for the primary actor
Secondary Actors other systems relied upon to accomplish use case
Trigger the action upon the system that starts the use case
DescriptionStep Action
1
...
Extensions or VariationsStep Branching Action
... condition causing branching
action or name of sub-use case
Massimo Felici Use Cases c© 2004–2011
20
How to Create Use Cases
Step 1. Identify and Describe the Actors
Step 2. Identify and Describe the Use Cases
Step 3. Identify the (Actor and Use Case) Relationships
Step 4. Individually Outline Use Cases
Step 5. Prioritize the Use Cases
Step 6. Refine the Use Cases
Massimo Felici Use Cases c© 2004–2011
Example 9 21
An ATM System
Massimo Felici Use Cases c© 2004–2011
An ATM System 22
Use Case Description: Withdraw moneyUse Case [number ]1] Withdraw money
Goal in ContextThis use case allows a card holder, who is not a
customer of the bank, to withdraw money if his or
her daily limit allows itPreconditions The ATM is well stocked and in serviceSuccess End Condition the CardHolder withdraws the required money
Failed End Condition ...
Primary Actor CardHolder
Secondary Actors The ATM Bank, The CardHolder’s Bank
Trigger The CardHolder introduces the card in the ATM
DescriptionStep Action
1
Extensions or VariationsStep Branching Action
Massimo Felici Use Cases c© 2004–2011
23
Required Readings
• UML course textbook, Chapter 3 on Use Cases
Massimo Felici Use Cases c© 2004–2011
24
Summary
• Use Cases in UML capture (to a certain extent) system requirements andsupport requirements engineering activities and processes
• Use Case notations and examples
• Describing use cases
• Developing use cases
Massimo Felici Use Cases c© 2004–2011
Software Design and Class Diagrams
Massimo Felici
Massimo Felici Software Design and Class Diagrams c© 2004–2011
1
Software Design
• The SEOC course is concerned with software design in terms of objects andcomponents, in particular, object-oriented design
• Object-oriented design is part of object-oriented development where an object-oriented strategy is used throughout the development process
• The main activities are: Object-oriented analysis, Object-oriented design,Object-oriented programming
Massimo Felici Software Design and Class Diagrams c© 2004–2011
2
Key Issues in Software Design
• Concurrency
• Workflow and event handling
• Distribution
• Error handling and recovery
• Persistence of data
• Can you think through some of these issues for the SEOC project?
Massimo Felici Software Design and Class Diagrams c© 2004–2011
3
Key Design Techniques
• Abstraction – ignoring detail to get the high level structure right
• Decomposition and Modularization – big systems are composed from smallcomponents
• Encapsulation/information hiding – the ability to hide detail (linked toabstraction)
• Defined interfaces – separable from implementation
• Evaluation of structure – Coupling: How interlinked a component is; Cohesion:How coherent a component is
Massimo Felici Software Design and Class Diagrams c© 2004–2011
4
Architecture and Structure
• Architectural structures and viewpoints• Architectural styles• Design patterns
small-scale patterns to guide the designer• Families and frameworks
component sets and ways of plugging them togethersoftware product lines
• Architectural design
Massimo Felici Software Design and Class Diagrams c© 2004–2011
5
Architecture Models
• A static structural model that shows the sub-systems or components thatare to be developed as separate units.
• A dynamic process model that shows how the system is organized intoprocesses at run-time. This may be different from the static model.
• An interface model that defines the services offered by each sub-systemthrough their public interface.
• A relationship model that shows relationships such as data flow between thesub-systems.
Massimo Felici Software Design and Class Diagrams c© 2004–2011
6
Class Diagrams
• Support architectural design
Provide a structural view of systems
• Represent the basics of Object-Oriented systems
Identify what classes there are, how they interrelate and how they interact
Capture the static structure of Object-Oriented systems – how systems arestructured rather than how they behave
• Constrain interactions and collaborations that support functional requirements
Link to Requirements
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Rationale 7
Class Diagrams
• Desirable to build systems quickly and cheaply (and to meet requirements)
• Desirable to make the system easy to maintain and modify
• Warnings
– The classes should be derived from the (user) domain - avoid abstractobjects
– Classes provide limited support to capture system behaviour – avoid tocapture non-functional requirements of the system as classes
Massimo Felici Software Design and Class Diagrams c© 2004–2011
8
Class Diagrams in the Life Cycle
• Used throughout the development life cycle
• Carry different information depending on the phase of the development processand the level of detail being considered
From the problem to implementation domain
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Basics 9
Class Diagrams
• Classes
– Basic Class Components– Attributes and Operations
• Class Relationships
– Associations– Generalizations– Aggregations and Compositions
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Construction 10
Class DiagramsConstruction involves
1. Modelling classes
2. Modelling relationships between classes, and
3. Refining and elaborate as necessary
Massimo Felici Software Design and Class Diagrams c© 2004–2011
11
Classes and Objects
• Classes represent groups of objects all with similar roles in the system
Structural features define what objects of the class know
Behavioral features define what objects of the class can do
• Classes may
inherit attributes and services from other classes
be used to create objects
• Objects are instances of classes, real-world and system entities
Massimo Felici Software Design and Class Diagrams c© 2004–2011
12
Basic Class Compartments
• Name
• Attributes
– represent the state of an object of the class– are descriptions of the structural or static features of a class
• Operations
– define the way in which objects may interact– are descriptions of behavioural or dynamic features of a class
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 13
Basic Class Compartments
Massimo Felici Software Design and Class Diagrams c© 2004–2011
14
Attribute Definitionvisibility / name : type multiplicity = default {property strings and constraints}
• visibility• / derived attribute - Attributes by relationship allow the definition of complex
attributes• name• type is the data type of the attribute or the data returned by the operation• multiplicity specifies how many instances of the attributes type are referenced
by this attribute• property strings: readOnly, union, subset ¡attribute-name¿, redefines
¡attribute-name¿ composite, ordered, bag, sequence, composite• constraints
Massimo Felici Software Design and Class Diagrams c© 2004–2011
15
Visibility
• From More accessible to Less Accessible
public (+), protected (]), package(∼), private (-)
• Warnings: Java allows access to protected parts of a class to anyclass in the same package
• Warnings: Although many languages use such terms as public,private, and protected, they mean different things in differentlanguages. The meanings of visibility markers can change fromlanguage to language.
Massimo Felici Software Design and Class Diagrams c© 2004–2011
16
MultiplicityMultiplicity specifies how many instances of the attributes type are referenced bythis attribute
• [n..m] – n to m instances
• 0..1 – zero or one instance
• 0..* or * – no limit on the number of instances (including none)
• 1 – exactly one instance
• 1..* – at least one instance
Massimo Felici Software Design and Class Diagrams c© 2004–2011
17
Operation Definitionvisibility name (parameters) : return-type {properties}
• (Parameters)direction parameter name : type [multiplicity] = default value properties
• direction: in, inout, out or return• Operation constraints: preconditions, postconditions, body conditions, query
operations, exceptions• Static operations: Specify behaviour for the class itself; Invoked directly on
the class• Methods are implementations of operations
Abstract classes provide operation signatures, but no implementations
Massimo Felici Software Design and Class Diagrams c© 2004–2011
18
Class RelationshipsRelationship Description
Dependency: objects of one class work brieflywith objects of another class
Association: objects of one class work withobjects of another class for some prolongedamount of timeAggregation: one class owns but share areference to objects of other class
Composition: one class contains objects ofanother class
Generalization (Inheritance): one class is atype of another class
Massimo Felici Software Design and Class Diagrams c© 2004–2011
19
Dependency
• A dependency exists between two elements if changes to the definition of oneelement (the supplier or target) may cause changes to the other (the client orsource)
• A Dependency between two classes means that one class uses, or has knowledgeof, another class (i.e., a transient relationship)
• Dependency relationships show that a model element requires another modelelement for some purpose
• Dependencies can also indicate relationships between model elements atdifferent level of abstraction
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Examples 20
Dependency
Massimo Felici Software Design and Class Diagrams c© 2004–2011
21
Association
• an attribute of an object is an associated object
• a method relies on an associated object
• an instance of one class must know about the other in order to perform itswork
• Passing messages and receiving responses
Associations may be annotated with information: Name, Multiplicity, Role Name,Ends, Navigation
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Examples 22
Association
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 23
Association
Massimo Felici Software Design and Class Diagrams c© 2004–2011
24
Association Class
• A class can be attached to an association, in which case it is called anassociation class
• The association class is not connected at any of the ends of the association,but is connected to the actual association
• Association classes allow you to add attributes, operations, and other featuresto associations
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 25
Association Class
Massimo Felici Software Design and Class Diagrams c© 2004–2011
26
Aggregation
• is a stronger version of association
• is used to indicate that, as well as having attributes of its own, an instance ofone class may consist of, or include, instances of another class
• are associations in which one class belongs to a collection
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 27
Aggregation
Massimo Felici Software Design and Class Diagrams c© 2004–2011
28
Composition
• Compositions imply coincident lifetime.
• A coincident lifetime means that when the whole end of the association iscreated (deleted), the part components are created (deleted).
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 29
Composition
Massimo Felici Software Design and Class Diagrams c© 2004–2011
30
Aggregation versus CompositionCriteria Decision Result
Part-of, contains, owns words are used to describerelationship between two classes
Aggregation orComposition
No symmetry Aggregation orComposition
Transitivity among parts Aggregation orComposition
Parts are not shared CompositionMultiplicity of the whole is 1 or 0..1 CompositionParts may be shared AggregationMultiplicity of the whole may be larger that 1 AggegrationRelationship does not fit the other criteria Association
Massimo Felici Software Design and Class Diagrams c© 2004–2011
31
Generalization (Inheritance)
• An inheritance link indicating one class is a superclass of the other, the subclass
– An object of a subclass to be used as a member of the superclass– The behaviour of the two specific classes on receiving the same message
should be similar
• Checking Generalizations: If class A is a generalization of a class B, then“Every B is an A”
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example1 32
Generalization (Inheritance)
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example2 33
Generalization (Inheritance)
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Implementing Generalizations 34
Generalization (Inheritance)
• Java: creating the subclass by extending the superclass
• Inheritance increases system coupling
• Modifying the superclass methods may require changes in many subclasses
• Restrict inheritance to conceptual modelling
• Avoid using inheritance when some other association is more appropriate
Massimo Felici Software Design and Class Diagrams c© 2004–2011
35
More on Classes
• Abstract Classes provide the definition, but not the implementation
• Interfaces are collections of operations that have no corresponding methodimplementations
– Safer than Abstract classes avoid many problems associated with multipleinheritance
– Java allows a class to implement any number of interface, but a class inheritfrom only one regular or abstract class
• Templates or parameterized classes allow us to postpone the decision as towhich classes a class will work with
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 36
Abstract Classes
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Example 37
Interface Classes
Massimo Felici Software Design and Class Diagrams c© 2004–2011
38
Template Classes
Massimo Felici Software Design and Class Diagrams c© 2004–2011
39
Modelling by Class Diagrams
• Class Diagrams (models)
– from a conceptual viewpoint, reflect the requirements of a problem domain– From a specification (or implementation) viewpoint, reflect the intended
design or implementation, respectively, of a software system
• Producing class diagrams involve the following iterative activities:
– Find classes and associations (directly from the use cases)– Identify attributes and operations and allocate to classes– Identify generalization structures
Massimo Felici Software Design and Class Diagrams c© 2004–2011
40
How to build a class diagram
• Design is driven by criterion of completeness either of data or responsibility– Data Driven Design identifies all the data and see it is covered by some
collection of objects of the classes of the system– Responsibility Driven Design identifies all the responsibilities of the system
and see they are covered by a collection of objects of the classes of thesystem
• Noun identification– Identify noun phrases: look at the use cases and identify a noun phrase.
Do this systematically and do not eliminate possibilities– Eliminate inappropriate candidates: those which are redundant, vague,
outside system scope, an attribute of the system, etc.• Validate the model...
Massimo Felici Software Design and Class Diagrams c© 2004–2011
41
Common Domain Modelling Mistakes
• Overly specific noun-phrase analysis
• Counter-intuitive or incomprehensible class and association names
• Assigning multiplicities to associations too soon
• Addressing implementation issues too early: Presuming a specificimplementation strategy, Committing to implementation constructs, Tacklingimplementation issues
• Optimising for reuse before checking use cases achieved
Massimo Felici Software Design and Class Diagrams c© 2004–2011
42
Class and Object Pitfalls
• Confusing basic class relationships (i.e., is-a, has-a, is-implemented-using)
• Poor use of inheritance
– Violating encapsulation and/or increasing coupling– Base classes do too much or too little– Not preserving base class invariants– Confusing interface inheritance with implementation inheritance– Using multiple inheritance to invert is-a
Massimo Felici Software Design and Class Diagrams c© 2004–2011
43
Required Readings
• UML course textbook
– Chapter 4 on Class Diagram: Classes and Associations– Chapter 5 on Class Diagram: Aggregation, Composition and Generalization– Chapter 6 on Class Diagram: More on Associations– Chapter 7 on Class Diagram: Other Notations
• P. Kruchten. The 4+1 View Model of architecture. IEEE Software, 12(6):42-50, November, 1995.
Massimo Felici Software Design and Class Diagrams c© 2004–2011
44
Suggested Readings
• Chapter 14 on Object-oriented design, I. Sommerville. Software Engineering,Eighth Edition, Addison-Wesley 2007.
• P. Kruchten, H. Obbink, J. Stafford. The Past, Present and Future of SoftwareArchitecture. IEEE Software, 23(2):22-30, March/April, 2006.
• B. Meyer. Applying “design by contract”. IEEE Computer, 25(10):40-51,1992.
Massimo Felici Software Design and Class Diagrams c© 2004–2011
45
Summary
• Design is a complex matter• Design links requirements to construction, essential to ensure traceability• Class Diagram Rationale• Classes• Class Relationships• Modelling by Class Diagrams• How to build a class diagram• Common domain modeling mistakes• Class and Object Pitfalls
Massimo Felici Software Design and Class Diagrams c© 2004–2011
Design Patterns
Massimo Felici
Massimo Felici Design Patterns c© 2004–2011
1
Reuse in Software Engineering
• Software Engineering is concerned with processes, techniques and tools whichenable us to build “good” systems
• Object-Orientation is a methodology, technique, process, suite of design andprogramming languages and tools with which we may build good systems
• Components are units of reuse and replacement
Massimo Felici Design Patterns c© 2004–2011
2
Examples of Types of Reuse
• Application system reuse: the whole of an application system may be reusedby incorporating it without change into other systems
• Component reuse: components of an application ranging in size from sub-systems to single objects may be reused
• Object and function reuse: software components that implement a singlefunction, such as a mathematical function or an object class, may be reused
Massimo Felici Design Patterns c© 2004–2011
3
Benefits of Software Reuse
• Increased dependability
• Reduced process risk
• Effective use of specialists
• Standards compliance
• Accelerated development
Massimo Felici Design Patterns c© 2004–2011
4
Problems with Software Reuse
• Increased maintenance costs
• Lack of tool support
• Not-invented-here syndrome
• Creating and maintaining a component library
• Finding, understanding and adapting reusable components
Massimo Felici Design Patterns c© 2004–2011
Key Factors 5
Planning Reuse
• The development schedule for the software
• The expected software lifetime
• The background, skills and experience of the development team
• The criticality of the software and its non-functional requirements
• The application domain
• The platform on which the system will run
Massimo Felici Design Patterns c© 2004–2011
6
Types of Reuse
• Reuse of Knowledge
– Artifact reuse– Pattern reuse
• Reuse of Software
– Code reuse– Inheritance reuse– Template reuse– Component reuse– Framework reuse
Massimo Felici Design Patterns c© 2004–2011
Reuse of Knowledge 7
Artifact Reuse
• Reuse of use cases, standards, design guidelines, domain-specific knowledge
• Pluses: consistency between projects, reduced management burden, globalcomparators of quality and knowledge
• Minuses: overheads, constraints on innovation (coder versus manager)
Massimo Felici Design Patterns c© 2004–2011
Reuse of Knowledge 8
Pattern Reuse
• A design pattern is a solution to a common problem in the design of computersystems
• Reuse of publicly documented approaches to solving problems (e.g., classdiagrams)
• Plusses: long life-span, applicable beyond current programming languages,applicable beyond Object Orientation?
• Minuses: no immediate solution, no actual code, knowledge hard tocapture/reuse.
Massimo Felici Design Patterns c© 2004–2011
9
Documenting Patterns
• Pattern Name• Classification• Intent• Also Known As• Motivation (Forces)• Applicability• Structure• Participants• Collaborations• Consequences• Implementation• Sample Code• Known Uses• Related Patterns
Massimo Felici Design Patterns c© 2004–2011
Example of Creational Pattern 10
BuilderSeparate the construction of a complex object from its representation so thatthe same construction process can create different representations
Massimo Felici Design Patterns c© 2004–2011
Example of Creational Pattern 11
Factory MethodDefine an interface for creating an object, but let subclasses decide which classto instantiate. Factory Method lets a class defer instantiation to subclasses
Massimo Felici Design Patterns c© 2004–2011
Example of Structural Pattern 12
AdapterConvert the interface of a class into another interface clients expect. Adapterlets classes work together that couldn’t otherwise because of incompatibleinterfaces
Massimo Felici Design Patterns c© 2004–2011
Example of Structural Pattern 13
CompositeCompose objects into tree structures to represent part-whole hierarchies.Composite lets clients treat individual objects and compositions of objectsuniformly
Massimo Felici Design Patterns c© 2004–2011
Example of Behavioral Pattern 14
ObserverDefine a one to many dependency between objects so that when one objectchanges state, all its dependents are notified automatically
Massimo Felici Design Patterns c© 2004–2011
Example of Behavioral Pattern 15
StateAllow an object to alter its behavior when its internal state changes. The objectwill appear to change its class
Massimo Felici Design Patterns c© 2004–2011
Example of Security Pattern 16
Role-Based Access ControlAssign rights based on the functions or tasks of people in an environment inwhich control of access to computing resources is required and where there isa large number of users, information types, or a large variety of resources –Describe how users can acquire rights based on their job functions or their taskassigned
Massimo Felici Design Patterns c© 2004–2011
17
How to use a pattern
• Does a patter exist that address the considered problem?
• Does the patterns documentation suggest alternative solutions?
• Is there a simple solution?
• Is the context of the pattern consistent with the context of the problem?
• Are the results of using the pattern acceptable?
• Are there constraints?
Massimo Felici Design Patterns c© 2004–2011
Reuse of Software 18
Code Reuse
• Reuse of (visible) source code - code reuse versus code salvage
• Pluses: reduces written code, reduces development and maintenance costs
• Minuses: can increase coupling, substantial initial investment
Massimo Felici Design Patterns c© 2004–2011
Reuse of Software 19
Inheritance
• Using inheritance to reuse code behaviour
• Pluses: takes advantage of existing behaviour, decrease development time andcost
• Minuses: can conflict with component reuse, can lead to fragile class hierarchy- difficult to maintain and enhance
Massimo Felici Design Patterns c© 2004–2011
Reuse of Software 20
Template Reuse
• Reuse of common data format/layout (e.g., document templates, web-pagetemplates, etc.)
• Pluses: increase consistency and quality, decrease data entry time
• Minuses: needs to be simple, easy to use, consistent among groups
Massimo Felici Design Patterns c© 2004–2011
Reuse of Software 21
Component Reuse
• Analogy to electronic circuits: software “plug-ins”
• Reuse of prebuilt, fully encapsulated “components”; typically self-sufficient andprovide only one concept (high cohesion)
• Pluses: greater scope for reuse, common platforms (e.g., JVM) morewidespread, third party component development
• Minuses: development time, genericity, need large libraries to be useful
Massimo Felici Design Patterns c© 2004–2011
Reuse of Software 22
Framework Reuse
• Collection of basic functionality of common technical or business domain(generic “circuit boards”) for components
• Pluses: can account for 80
• Minuses: substantial complexity, leading to long learning process, platformspecific, framework compatibility issues leading to vendor specificity, implementeasy 80
Massimo Felici Design Patterns c© 2004–2011
23
Reuse Pitfalls
• Underestimating the difficulty of reuse
• Having or setting unrealistic expectations
• Not investing in reuse
• Being too focused on code reuse
• Generalising after the fact
• Allowing too many connections
Massimo Felici Design Patterns c© 2004–2011
24
Difficulties with Component Development
• Economic
– Small business do not have long term stability and freedom required
• Where is the third party component market?
– Effort in (re)using components– Cross-platform and cross-vendor compatibility– Many common concepts, few common components– Some success: user interfaces, data management, thread management, data
sharing between applications– Most successful: GUIs and data handling (e.g., Abstract Data Types)
Massimo Felici Design Patterns c© 2004–2011
25
ReadingsRequired Readings
• UML course textbook, Chapter 17 on Design Patterns• T. Winn, P. Calder. Is This a Pattern?. IEEE Software 19(1):59-66,
January/February, 2002.
Suggested Readings
• E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements ofReusable Object-Oriented Software. Addison-Wesley, 1995.
• M. Schumacher, E. Fernandez-Buglioni, D. Hybertson, F. Bushmann, P.Sommerlad. Security Patterns: Integrating Security and Systems Engineering.John Wiley & Sons, 2006.
Massimo Felici Design Patterns c© 2004–2011
26
Summary
• Many types of reuse (of both knowledge and software)
– Each has pluses and minuses
• Component reuse is a form of software reuse
– Encapsulation, high cohesion, specified interfaces explicit contextdependencies
– Component development requires significant time and effort, as doescomponent reuse
– Component reuse has been successful for interfaces and data handling
• Employing reuse requires management
Massimo Felici Design Patterns c© 2004–2011
Validation: CRC Cards
Massimo Felici
Massimo Felici Validation: CRC Cards c© 2004–2011
What are CRC Cards? 1
CRC Cards
• CRC: Class-Responsibility-Collaborator
• CRC cards provide the means to validate the class model with the use casemodel
• Responsibilities are a way to state the rationale of the system design
• CRC cards support responsibility-based modelling
Massimo Felici Validation: CRC Cards c© 2004–2011
How do they look like? 2
CRC CardsCRC Cards explicitly represent multiple objects simultaneously
1. The Name of the class it refers to2. The Responsibilities of the class
These should be high level, not at the level of individual methods3. The Collaborators that help discharge a responsibility
Massimo Felici Validation: CRC Cards c© 2004–2011
3
Design by Responsibilities
• Responsibility-based Modelling allows
– The identification of the components from which the system is constructed– The allocation of responsibilities to system components– The identification of the services (or functionalities) provided by them– The assessment how components satisfy the requirements as stated by the
use cases
• Types of Responsibilities
– To do something (active responsibilities)– To provide information (acting as a contact point)
Massimo Felici Validation: CRC Cards c© 2004–2011
4
Steps in Responsibility-based Design1 Identify scenarios of use; bound the scope
of design
2 Role play the scenarios, evaluating
responsibilities
3 Name the required responsibilities to
carry a scenario toward
4 Make sure that each component has
sufficient information and ability to carry
out its responsibility
5 Consider variations of the scenario; check
the stability of the responsibility
6 Evaluate the components
7 Ask the volatility / stability of the
component
8 Create variations
9 Run through the variant scenarios
to investigate the stability of the
components and responsibilities
10 Simulate if possible
11 Consolidate the components by level
12 Identify subsystems
13 Identify the different levels
14 Document the design rationale and key
scenarios
15 Decide which scenarios to document
16 List the components being used that
already exist
17 Specify each new component
Massimo Felici Validation: CRC Cards c© 2004–2011
5
Design Activities
1. Preparation: collection and selection of use cases
2. Invention: (incremental) identification of components and responsibilities
3. Evaluation: questions and scenarios stress test the design
4. Consolidation: further assessment of the tested components
5. Documentation: recording identified reasons and scenarios
Massimo Felici Validation: CRC Cards c© 2004–2011
6
CRC Cards in Design Development
1. Work using role play – different individuals are different objects
2. Pick a use case to building a scenario to hand simulate
3. Start with the person who has the card with the responsibility to initiate theuse case
4. In discharging a responsibility a card owner may only talk to collaborators forthat responsibility
5. Gaps must be repaid and re-tested against the use case
Massimo Felici Validation: CRC Cards c© 2004–2011
7
Using CRC Cards
1. Choose a coherent set of use cases
2. Put a card on the table
3. Walk through the scenario, naming cards and responsibilities
4. Vary the situations (i.e., assumptions on the use case), to stress test the cards
5. Add cards, push cards to the side, to let the design evolve (that is, evaluatedifferent design alternatives)
6. Write down the key responsibility decisions and interactions
Massimo Felici Validation: CRC Cards c© 2004–2011
Example – Requirements 8
A Library System
1. The library system must keep track of when books are borrowed and returned
2. The system must support librarian work
3. The library is open to university staff and students
4. University staff can borrow up to 25 different books
5. Students can borrow up to 15 different books
Massimo Felici Validation: CRC Cards c© 2004–2011
Example – Use Cases 9
A Library System
Massimo Felici Validation: CRC Cards c© 2004–2011
Example – Class Diagram 10
A Library System
Massimo Felici Validation: CRC Cards c© 2004–2011
Example – CRC Cards 11
A Library System
Massimo Felici Validation: CRC Cards c© 2004–2011
Example – A CRC Game 12
A Library System
Massimo Felici Validation: CRC Cards c© 2004–2011
13
What CRC Card help with
• Check use case can be achieved
• Check associations are correct
• Check generalizations are correct
• Detect omitted classes
• Detect opportunities to refactor the class model, that is, to move responsibilitiesabout (and operations in the class model) without altering the overallresponsibility of the system
Massimo Felici Validation: CRC Cards c© 2004–2011
14
CRC Cards and Quality
• CRC Cards– provide a good, early, measure of the quality of the system (design) – solving
problems now is better that later– are flexible - use them to record changes during validation
• Too many responsibilities– This indicates low cohesion in the system– Each class should have at most three or four responsibilities– Classes with more responsibilities should be split if possible
• Too many collaborators– This indicates high coupling– It may be the division of the responsibilities amongst the classes is wrong
Massimo Felici Validation: CRC Cards c© 2004–2011
15
Principles for Refactoring
• Do not do both refactoring and adding functionality at the same time
• Make sure you have good tests before you begin refactoring
• Take short deliberate steps
Massimo Felici Validation: CRC Cards c© 2004–2011
16
When to Refactor?
• When you are adding a function to your design (program) and you find the olddesign (code) getting in the way
• When you are looking at design (code) and having difficulty understanding it
Massimo Felici Validation: CRC Cards c© 2004–2011
17
OO Design using CRC Cards
1. Review quality of class model
2. Identify opportunities for refactoring
3. Identify (new) classes that support system implementation
4. Identify further details (e.g., sub-responsibilities of class responsibilities,attributes, object creations, destructions and lifetimes, passed data, etc.)
Massimo Felici Validation: CRC Cards c© 2004–2011
18
OO Analysis using CRC Cards
1. Session focuses on a part of requirements
2. Identify classes (e.g., noun-phrase analysis)
3. Construct CRC cards for these and assign to members
4. Add responsibilities to classes
5. Role-play scenarios to identify collaborators
Massimo Felici Validation: CRC Cards c© 2004–2011
19
Common Domain Modelling Mistakes
• Overlay specific noun-phrase analysis
• Counter-intuitive or incomprehensible class and association names
• Assigning multiplicities to associations too soon
• Addressing implementation issues too early
– Presuming a specific implementation strategy– Committing to implementation constructs– Tackling implementation issues (e.g., integrating legacy systems)
• Optimising for reuse before checking use cases achieved
Massimo Felici Validation: CRC Cards c© 2004–2011
20
Readings
Required Readings
• K. Beck, W. Cunningham. A Laboratory for Teaching Object-OrientedThinking. In Conference Proceedings on Object-Oriented ProgrammingSystems, Languages and Applications (OOPSLA ’89), ACM, pp. 1-6.
Suggested Readings
• T. Mens, T. Tourwe. A survey of software refactoring. IEEE Transactions onSoftware Engineering, vol.30, no.2, pp. 126-139, February, 2004.
Massimo Felici Validation: CRC Cards c© 2004–2011
21
Summary
• We should try to check the completeness of the class model (early assurancethe model is correct)
• CRC Cards are a simple way of doing this
• CRC Cards support responsibility-based modeling and design
• CRC Cards identify errors and omissions
• They also give an early indication of quality
• Use the experience of simulating the system to refactor if this necessary
Massimo Felici Validation: CRC Cards c© 2004–2011
Component Diagrams
Massimo Felici
Massimo Felici Component Diagrams c© 2004–2011
Rationale 1
Component Diagrams
• A component is an encapsulated, reusable, and replaceable part of your software
• Reducing and defying coupling between software components
• Reusing existing components
Massimo Felici Component Diagrams c© 2004–2011
Slide 1: Component Diagrams
The ability to identify software components (which are encapsulated, reusable andreplaceable) supports development strategies that use, e.g., COTS (Commercial-Off-The-Shelf) components.
Required Readings
• UML course textbook, Chapter 8 on Component Diagrams
2
Component Diagrams
• Model physical software components and the interfaces between them
• Show the structure of the code itself
• Can be used to hide the specification detail (i.e., information hiding) and focuson the relationship between components
• Model the structure of software releases; show how components integrate withcurrent system design
• Model source code and relationships between files
• Specify the files that are compiled into an executable
Massimo Felici Component Diagrams c© 2004–2011
Slide 2: Component Diagrams
Components have interfaces and context dependencies (i.e., implementation-specific shown on diagram; use-context may be described elsewhere, for example,documentation, use-cases, interaction diagrams, etc.).
3
Component Notation
A Component is a physical piece of a system, such as a compiled object file, pieceof source code, shared library or Enterprise Java Bean (EJB).
Massimo Felici Component Diagrams c© 2004–2011
Slide 3: Component Notation
Note that UML 2.0 uses a new notation for a component. Previous UML versionsuse the component icon as the main shape.
4
Component Interfaces
Massimo Felici Component Diagrams c© 2004–2011
Slide 4: Component Interfaces
• A provided interface of a component is an interface that the componentrealises
• A required interface of a component is an interface that the componentneeds to function
Slide 4: Component Interfaces
Class interfaces have similar notations (definitions).
• Provided interfaces define “a set of public attributes and operations that mustbe provided by the classes that implement a given interface”.
• Required interfaces define “a set of public attributes and operations that arerequired by the classes that depend upon a given interface”.
Java Warnings: Note that these definitions of interfaces differ from the Javadefinition of interfaces. The Java definition of interfaces does not allow to haveattributes, nor hence state.
Required Readings
• UML course textbook, Chapter 7 on Class Diagram: Other Notations
5
Component AssembliesComponents can be “wired” together to form subsystems
Massimo Felici Component Diagrams c© 2004–2011
6
PortsA port (definition) indicates that the component itself does not provide therequired interfaces (e.g., required or provided). Instead, the component delegatesthe interface(s) to an internal class.
Massimo Felici Component Diagrams c© 2004–2011
Slide 6: Ports
Component Realisation. A component might implement (realise) the providedinterfaces for the component, or it may delegate that realisation to other classesthat make up that component. The realisation dependency can be shown in threeways:
1. listing the realisation classes
2. using realisation dependency relationships
3. showing containment graphically.
Ports Forwarding and Filtering. Ports connect to the required and providedinterfaces on the outside of the class. They can also connect to the classes of thecomponent itself.
7
Component Diagrams
• Component Diagrams can show how subsystems relate and which interfacesare implemented by which component.
• A Component Diagram shows one or more interfaces and their relationships toother components.
• A Component Diagram shows the dependencies among software components,including source code, binary code and executable components.
• Some components exist at compile time, some exist at link time, and someexist at run time; some exist at more that one time.
Massimo Felici Component Diagrams c© 2004–2011
Slide 7: Dependencies
Reside Dependencies. A reside dependency from a component to any UMLelement indicates that the component is a client of the element, which isconsidered itself a supplier, and that the element resides in the component.
Use Dependencies. A use dependency from a client component to a suppliercomponent indicates that the client component uses or depends on thesupplier component. A use dependency from a client component to a suppliercomponents interface indicates that the client component uses or depends onthe interface provided by the supplier component.
Deploy Dependency. A deploy component from a client component to asupplier node indicates that the client components is deployed on the suppliernode.
8
Component Modelling
1. Find components and dependencies
2. Identify and level subcomponents
3. Clarify and make explicit the interfaces between components
Massimo Felici Component Diagrams c© 2004–2011
9
When to use component diagrams
Use component diagrams when you are dividing your system into componentsand want to show their interrelationships through interfaces or the breakdownof components into a lower-level structure.
Massimo Felici Component Diagrams c© 2004–2011
10
How to produce component diagrams
• Decide on the purpose of the diagram
• Add components to the diagram, grouping them within other components ifappropriate
• Add other elements to the diagram, such as classes, objects and interfaces
• Add the dependencies between the elements of the diagram
Massimo Felici Component Diagrams c© 2004–2011
11
Required Readings
• UML course textbook, Chapter 7 on Class Diagram: Other Notations
• UML course textbook, Chapter 8 on Component Diagrams
Massimo Felici Component Diagrams c© 2004–2011
12
Summary
• Component Rationale
• Notation
• Component Diagrams
• Modelling
Massimo Felici Component Diagrams c© 2004–2011
Sequence Diagrams
Massimo Felici
Massimo Felici Sequence Diagrams c© 2004–2011
1
What are Sequence Diagrams?
• Sequence Diagrams are interaction diagrams that detail how operations arecarried out
• Interaction diagrams model important runtime interactions between the partsthat make up the system
• Interactions Diagrams
– Sequence diagrams– Interaction overview diagrams– Timing diagrams– Communication diagrams
Massimo Felici Sequence Diagrams c© 2004–2011
2
What do Sequence Diagrams model?
• capture the interaction between objects in the context of a collaboration
• show object instances that play the roles defined in a collaboration
• show the order of the interaction visually by using the vertical axis of thediagram to represent time what messages are sent and when
• show elements as they interact over time, showing interactions or interactioninstances
• do not show the structural relationships between objects
Massimo Felici Sequence Diagrams c© 2004–2011
3
Participants in a Sequence Diagram
• A sequence diagram is made up of a collection of participants
• Participants – the system parts that interact each other during the sequence
• Classes or Objects – each class (object) in the interaction is represented by itsnamed icon along the top of the diagram
Massimo Felici Sequence Diagrams c© 2004–2011
Notations 4
Sequence Diagrams
• Frames• Lifelines• Messages and Focus Control• Combined Fragments• Interaction Occurrences• States• Continuations• Textual Annotation• Tabular Notation
Massimo Felici Sequence Diagrams c© 2004–2011
5
Frames
Massimo Felici Sequence Diagrams c© 2004–2011
6
Lifelines
• Sequence diagrams are organised according to time• Each participant has a corresponding lifeline• Each vertical dotted line is a lifeline, representing the time that an object exists• Lifeline name:
[connectable-element-name][‘[‘selector’]’][:class-name][decomposition]
Massimo Felici Sequence Diagrams c© 2004–2011
Examples 7
Lifelines NamesSyntax Explanation
seoclecturer An object named secolecturer
seoclecturer:Lecturer An object named seoclecturer of classLectuer
:Lecturer An anonymous object of class Lecturer
lecturer[i] The object lecturer that is selected by theindex value i
s ref sd3 A subsystem s whose internal interactionis shown in sequence diagram sd3(decomposition)
self The connectable element that owns theinteraction shown in the sequence diagram
Massimo Felici Sequence Diagrams c© 2004–2011
8
Messages and Focus of Control
Massimo Felici Sequence Diagrams c© 2004–2011
9
Messages
• Messages (or signals) on a sequence diagram are specified using an arrowfrom the participant (message caller) that wants to pass the message to theparticipant (message receiver) that is to receive the message
• A Message (or stimulus) is represented as an arrow going from the sender tothe top of the focus of control (i.e., execution occurrence) of the message onthe receiver’s lifeline
Massimo Felici Sequence Diagrams c© 2004–2011
10
Message Type NotationsMessage Description
Synchronous: A synchronous message between active
objects indicates wait semantics; the sender waits for the
message to be handled before it continues. This typically
shows a method call.
Asynchronous: With an asynchronous flow of control,
there is no explicit return message to the caller. An
asynchronous message between objects indicates no-wait
semantics; the sender does not wait for the message before
it continues. This allows objects to execute concurrently.
Reply: This shows the return message from another
message.
Massimo Felici Sequence Diagrams c© 2004–2011
11
Message Type NotationsMessage Description
Create: This message results in the creation of a new
object. The message could call a constructor for a class if
you are working with Java, for example.
Lost: A lost message occurs whet the sender of the
message is known but there is no reception of the message.
This message allows advanced dynamic models to built
up by fragments without complete knowledge of all the
messages in the system. This also allows the modeler to
consider the possible impact of a message’s being lost.
Found: A found message indicates that although the
receiver of the message is known in the current interaction
fragment, the sender of the message is unknown.
Massimo Felici Sequence Diagrams c© 2004–2011
Example 12
A sequence diagram for distributed control
Massimo Felici Sequence Diagrams c© 2004–2011
13
Sequence Fragments
• UML 2.0 introduces sequence (or interaction) fragments
• Sequence fragments make it easier to create and maintain accurate sequencediagrams
• A sequence fragment is represented as a box, called a combined fragment,which encloses a portion of the interactions within a sequence diagram
• The fragment operator (in the top left cornet) indicates the type of fragment
• Fragment types: ref, assert, loop, break, alt, opt, neg
Massimo Felici Sequence Diagrams c© 2004–2011
Notation 14
Sequence Fragments
Massimo Felici Sequence Diagrams c© 2004–2011
15
Common Operators for Interaction FramesOperator Meaning
alt Alternative multiple fragments: only the one whose condition is true will
execute.
opt Optional: the fragment executes only if the supplied condition is true.
Equivalent to an alt only with one trace.
par Parallel: each fragment is run in parallel.
loop Loop: the fragment may execute multiple times, and the guard indicates the
basis of iteration.
region Critical region: the fragment can have only one thread executing it at once.
neg Negative: the fragment shows an invalid interaction.
ref Reference: refers to an interaction defined on another diagram. The frame
is drawn to cover the lifelines involved in the interaction. You can define
parameters and a return value.
sd Sequence diagram: used to surround an entire sequence diagram.
Massimo Felici Sequence Diagrams c© 2004–2011
Example 16
Interaction Frames
Massimo Felici Sequence Diagrams c© 2004–2011
17
Other Notations
• States - it is possible to place states on lifelines (e.g., pre and post conditions)
• Textual notations (e.g., comments, time constraints, duration constraints)
• Tabular notation
Massimo Felici Sequence Diagrams c© 2004–2011
18
Timing
• Constraints are usually used to show timing constraints on messages. Theycan apply to the timing of one message or intervals between messages.
• Durations – The duration of activations or the time between messages can beshow with construction marks.
Massimo Felici Sequence Diagrams c© 2004–2011
Example 19
Timing
Massimo Felici Sequence Diagrams c© 2004–2011
20
How to Produce Sequence Diagrams
1. Decide on Context: Identify behavior (or use case) to be specified
2. Identify structural elements:
(a) Model objects (classes)(b) Model lifelines(c) Model activations(d) Model messages(e) Model Timing constraints
3. Refine and elaborate as required
Massimo Felici Sequence Diagrams c© 2004–2011
21
When to Use Sequence Diagrams
• You should use sequence diagrams when you want to look at the behaviour ofseveral objects within a single use case.
• Sequence diagrams are good at showing collaborations among the objects.
• They are not so good at precise definition of behaviour.
Massimo Felici Sequence Diagrams c© 2004–2011
22
How do Interaction Diagrams help?
• Check use cases
• Check class can provide an operation – showing how a class realizes someoperation by interacting with other objects
• Describe design pattern – parameterising by class provides a scheme for ageneric interaction (part of Software Architecture)
• Describe how to use a component – capturing how components can interact
Massimo Felici Sequence Diagrams c© 2004–2011
23
Required Readings
• UML course textbook, Chapter 9 on Interaction Sequence Diagrams
Massimo Felici Sequence Diagrams c© 2004–2011
24
Summary
• Sequence Diagrams
– capture some elements of the dynamics of systems– support a number of different activities– describe interaction in some detail, including timing
• Dimensions – Objects and Time
• Basics – Objects, Lifelines, Activations, Messages, etc.
• Timing
Massimo Felici Sequence Diagrams c© 2004–2011
Communication Diagrams
Massimo Felici
Massimo Felici Communication Diagrams c© 2004–2011
1
Realizing Use cases in the Design Model
Massimo Felici Communication Diagrams c© 2004–2011
Rationale 2
Communication Diagrams
• Model collaborations between objects or roles that deliver the functionalitiesof use cases and operations
• Model mechanisms within the architectural design of the system
• Capture interactions that show the passed messages between objects and roleswithin the collaboration
• Model alternative scenarios within use cases or operations that involve thecollaboration of different objects and interactions
• Support the identification of objects (hence classes) that participate in usecases
Massimo Felici Communication Diagrams c© 2004–2011
3
Communication Diagrams
• The communication is implicit in a Sequence Diagram, rather than explicitlyrepresented as in a Communication Diagram
• There is some redundancy between Communication and Sequence Diagrams
– They differently show how elements interact over time– They document in detail how classes realize user cases– Communication Diagrams show relationship between objects– Sequence Diagrams focus on the time in which events occur
Massimo Felici Communication Diagrams c© 2004–2011
Example 4
Sequence and Communication Diagrams
Massimo Felici Communication Diagrams c© 2004–2011
What is a Collaboration? 5
Communication Diagrams
• A Collaboration is a collection of named objects and actors with links connectingthem
• A Collaboration defines a set of participants and relationships that aremeaningful for a given set of purposes
• A Collaboration between objects working together provides emergent desirablefunctionalities in Object-Oriented systems
• Objects collaborate by communicating (passing messages) with one another inorder to work together
Massimo Felici Communication Diagrams c© 2004–2011
6
Collaborations
Actors• Each Actor is named and has a role• One actor will be the initiator of the use case
Objects• Each object in the collaboration is named and has its class specified• Not all classes need to appear• There may be more than one object of a class
Links• Links connect objects and actors and are instances of associations• Each link corresponds to an association in the class diagram
Massimo Felici Communication Diagrams c© 2004–2011
7
Interactions
• Use Cases and Class Diagrams constrain interactions
• Associations and Links in a Collaboration Diagram show the paths along whichmessages can be sent from one instance to another
• A message is the specification of a stimulus
• A stimulus represents a specific instance of sending the message, with particulararguments
Massimo Felici Communication Diagrams c© 2004–2011
Specification and Instance Levels 8
Communication Diagrams
• Specification level shows generic cases of collaborations (communications)
Generic form captures a collaboration among class roles and association rolesand their interactions
• Instance level shows a specific instance of an interaction taking place andinvolving specific object instances
Instance form captures a scenario among objects conforming to class roles andlinks conforming to association roles
Massimo Felici Communication Diagrams c© 2004–2011
9
Lifelines and Links
• Participants on a collaboration diagram are represented by a rectangle
• The syntax for the name of a lifeline
[connectable-element-name][‘[‘selector’]’][:class-name][decomposition]
• A communication link is shown with a single line that connects two participants
Massimo Felici Communication Diagrams c© 2004–2011
Simple Example 10
Communication Diagrams
Massimo Felici Communication Diagrams c© 2004–2011
11
Messages
• A message on a communication diagram is shown using an arrow from themessage sender to the message receiver
• Message Signature: return-value, message-name, argument-list
• Each message in a collaboration diagram has a sequence number. The top-levelmessage is numbered 1. Messages sent during the same call have the samedecimal prefix but suffixes of 1, 2, etc. according to when they occur.
Massimo Felici Communication Diagrams c© 2004–2011
12
Messages
Synchronous Asynchronous
Creation Reply
Massimo Felici Communication Diagrams c© 2004–2011
13
Messages
• Procedural or Synchronous: A message is sent by one object to another andthe first object waits until the resulting action has completed.
• Asynchronous: A message is sent by one object to another, but the first objectdoes not wait until the resulting action has completed.
• Flat: Each arrow shows a progression from one step to the next in a sequence.Normally the message is asynchronous.
• Return: the explicit return of control from the object to which the messagewas sent.
Massimo Felici Communication Diagrams c© 2004–2011
14
Messages
• Messages occurring at the same time: Adding a number-and-letter notation toindicate that a message happens at the same time as another message
• Invoking a message multiple times: Looping constraint, e.g., *[i=0..9]
• Sending a message based on a condition: A guardian condition is made up ofa logical boolean statement, e.g., [condition=true]
• When a participant sends a message to itself
Massimo Felici Communication Diagrams c© 2004–2011
Where should messages go? 15
Messages
• The message is directed from sender to receiver
• The receiver must understand the message
• The association must be navigable in that direction
• Law of Demeter
• Dealing with a message m an Object O can send messages to:
– Itself– Objects sent as argument in the message m– Objects O creates in responding to m– Objects that are directly accessible from O, using attribute values
Massimo Felici Communication Diagrams c© 2004–2011
Activations 16
Flow of Control
– Procedural interactionsAt most one object is computing at any time
– ActivationAn object has a live activation from when it receives a message until it respondsto the message
– Waiting for responseSynchronous messages on sending a message to another object, an object willwait until it receives a response
– Activation taskActivations are stacked and the top activation has control. When the topaction responds the next to top regains control and so on...
Massimo Felici Communication Diagrams c© 2004–2011
17
Creation and Deletion
• In Sequence Diagrams, It is possible to use the lifelines
– New objects have their icon inserted when they are created– Destroyed objects have their lifeline terminated with ×
• In Communication Diagrams the objects are labelled:
– New for objects created in the collaboration– Destroyed for objects destroyed during the collaboration
Massimo Felici Communication Diagrams c© 2004–2011
18
Communication vs. Sequence Diagrams
Communication SequenceDiagrams Diagrams
Participants ! !
Links !
Message Signature ! !
Parallel Messages ! !
Asynchronous messages !
Message Ordering !
Create & Maintain !
Massimo Felici Communication Diagrams c© 2004–2011
19
Constructing Communication Diagrams
1. Identify behaviour
2. Identify the structural elements
3. Model structural relationships
4. Consider the alternative scenarios
Massimo Felici Communication Diagrams c© 2004–2011
20
Readings
Required Readings
• UML course textbook, Chapter 10 on More on Interaction Diagrams
Suggested Readings
• K.J. Lieberherr, I.M. Holland. Assuring good style for object-oriented programs.IEEE Software 6(5):38-48, 1989.
Massimo Felici Communication Diagrams c© 2004–2011
21
Summary
• Interaction Diagrams
– Sequence Diagrams– Communication Diagrams
• Communication Diagrams Rationale
• Communication Diagrams
– Collaborations– Interactions– Messages
• Constructing Communication Diagrams
Massimo Felici Communication Diagrams c© 2004–2011
Activity Diagrams
Massimo Felici
Massimo Felici Activity Diagrams c© 2004–2011
1
Activity Diagrams
• Activity Diagrams consist of activities, states and transitions between activitiesand states
• Activity Diagrams describe
– how activities are coordinated to provide a service– the events needed to achieve some operation– how the events in a single use case relate to one another– how a collection of use cases coordinate to create a workflow for an
organisation
Massimo Felici Activity Diagrams c© 2004–2011
Rationale 2
Activity Diagrams
• Model business workflows
• Identify candidate use cases, through the examination of business workflows
• Identify pre- and post-conditions for use cases
• Model workflows between/within use cases
• Model complex workflows in operations on objects
• Model in detail complex activities in a high level activity diagram
Massimo Felici Activity Diagrams c© 2004–2011
Basics 3
Activity Diagrams
• Activities and Actions• Transitions and Activity Edges• Tokens and Activity Nodes• Control Nodes
– Initial and Final Nodes– Forks and Joins– Decision and Merge Points
• States• Swimlanes
Massimo Felici Activity Diagrams c© 2004–2011
Example 4
Activity Diagram
Massimo Felici Activity Diagrams c© 2004–2011
5
Activities
• An Activity is the process being modelled
• Activities are the vertices of the diagram
• An Activity is a unit of work that needs to be carried out
• Any Activity takes time
• An activity is like a state where the criterion for leaving the state is thecompletion of the activity
Massimo Felici Activity Diagrams c© 2004–2011
6
Actions
• An Action is a step in the overall activity
• The work can be documented as Actions in the activity
• There are four ways in which an action can be triggered
1. On Entry – as soon as the activity starts2. Do – during lifetime of the activity3. On Event – in response to an event4. On Exit – just before the activity completes
Massimo Felici Activity Diagrams c© 2004–2011
7
Transitions
• A Transition is the movement from one activity to another, the change fromone state to another, or the movement between a state and an activity ineither direction
• Transitions: unlabelled arrows from one activity to the next
• Transitions take place when one activity is complete and the next can commence
Massimo Felici Activity Diagrams c© 2004–2011
8
Activity Edges
• The flow of an activity is shown using arrowed lines called edges or paths
• Control-flow Transitions indicate the order of action states
• Object-flow Transitions indicate that an action state inputs or outputs anobject
Massimo Felici Activity Diagrams c© 2004–2011
9
Tokens
• Conceptually, UML models information moving along an edge as a token (e.g.,real data, an object or focus of control)
• Each edge may have
– a weight associated with it that indicates how many tokens must beavailable before the tokens are presented to the target action
– a guard condition
Massimo Felici Activity Diagrams c© 2004–2011
10
Activity Nodes
• UML 2.0 defines several types of activity nodes to model different types ofinformation flow
– Parameters nodes– Object nodes– (input or output) Pins - special notation for object nodes; exception pins,
value pins
Massimo Felici Activity Diagrams c© 2004–2011
Example 11
Flows and Edges
Massimo Felici Activity Diagrams c© 2004–2011
12
Initial and Final Nodes
• An initial node is the starting point for an activity
• Two types of final nodes: activity final and flow final
• An activity final node terminates the entire activity
• A flow final node terminates a path through an activity, but not the entireactivity
• It is possible to have multiple initial nodes and final nodes
Massimo Felici Activity Diagrams c© 2004–2011
Example 13
Final Nodes
Warnings: be careful when using a flow final node after a fork. As soon as theactivity final node is reached, all other actions in the activity (including the onesbefore the final flow node) terminate. If you want all forked actions to finish,make sure to add a join.
Massimo Felici Activity Diagrams c© 2004–2011
14
Forks
• A transition can be split into multiple paths and multiple paths combined intoa single transitions by using a synchronisation bar
• A synchronisation may have many in-arcs from activities and a number ofout-arcs to activities
• A fork is where the paths split
• On an occurrence of the transition all the activities with arcs from the transitionare initiated
• A fork node splits the current flow through an activity into multiple concurrentflows
Massimo Felici Activity Diagrams c© 2004–2011
15
Joins
• A join is where the paths meet
• The bar represents synchronisation of the completion of those activities witharcs into the transition
• A join synchronises multiple flows of an activity back to a single flow ofexecution
Massimo Felici Activity Diagrams c© 2004–2011
16
Decision and Merge Points
• A decision point shows where the exit transition from a state or activity maybranch in alternative directions depending on a condition
• A decision involves selecting one control-flow transition out of many control-flow transitions based on a condition
• Each branched edge contains a guard condition
• Guard expressions (inside []) label the transitions coming out of a branch
• A merge point brings together alternate flows into a single output flow - notethat it does not synchronise multiple concurrent flows
Massimo Felici Activity Diagrams c© 2004–2011
17
States
• A state in an activity diagram is a point where some event needs to take placebefore activity can continue
• Activities and States are similar
– States carry out actions as activities do– Activities need to complete their actions before exiting– States are used to imply waiting, not doing
• It is possible to show an object changing states as it flows through an activity
Massimo Felici Activity Diagrams c© 2004–2011
18
Start and End States
• The Start state is the entry point to a flow
• There can be several End states – multiple End states can be used to indicateddifferent follow-on processes from a particular process
• Start and End states can have actions too
• Malformed diagrams – it is possible to form ill-formed diagrams that requiremultiple activations of activities or can allow deadlock
Massimo Felici Activity Diagrams c© 2004–2011
19
Swimlanes
• Swimlanes (or activity partitions) indicate where activities take place.
• Swimlanes can also be used to identify areas at the technology level whereactivities are carried out
• Swimlanes allow the partition an activity diagram so that parts of it appear inthe swimlane relevant to that element in the partition
Massimo Felici Activity Diagrams c© 2004–2011
20
Sending and Receiving Signals
• In activity diagrams, signals represent interactions with external participants
• Signals are messages that can be sent or received
• A receive signal has the effect of waking up an action in your activity diagram
• Send signals are signals sent to external participants
Massimo Felici Activity Diagrams c© 2004–2011
Example 21
Signals on Activity Diagrams
Massimo Felici Activity Diagrams c© 2004–2011
Example 22
Sending and Receiving Signals
Massimo Felici Activity Diagrams c© 2004–2011
Activity Diagrams for Use Case Modelling 23
How to construct Activity Diagrams
1. Finding system Actors, Classes and use cases2. Identifying key scenarios of system use cases3. Combining the scenarios to produce comprehensive workflows described using
activity diagrams4. Where significant object behaviour is triggered by a workflow, adding object
flows to the diagrams5. Where workflows cross technology boundaries, using swimlanes to map the
activities6. Refining complicated high level activities similarly, nested activity diagrams
Massimo Felici Activity Diagrams c© 2004–2011
Activity Diagrams for Business Modelling 24
How to construct Activity Diagrams
1. Finding business actors and use cases
2. Identifying key scenarios of business use cases
3. Combining the scenarios to produce comprehensive workflows described usingactivity diagrams
4. Where appropriate, mapping activities to business areas and recording thisusing swimlanes
5. Refining complicated high level activities similarly, nested activity diagrams
Massimo Felici Activity Diagrams c© 2004–2011
25
Readings
Required Readings
• UML course textbook, Chapter 11 on Activities
Massimo Felici Activity Diagrams c© 2004–2011
26
Summary
• Activity Diagrams are good for describing synchronization and concurrencybetween activities
• Activity diagrams are useful for capturing detailed activities, but they can alsocapture elements of the high level workflow the system is intended to support
• Partitioning can be helpful in investigating responsibilities for interactions andassociations between objects and actors
Massimo Felici Activity Diagrams c© 2004–2011
State Machines
Massimo Felici
Massimo Felici State Machines c© 2004–2011
1
State Machines
• State Machines or Statechart Diagrams give us the means to controldecisions
• Each state is like a ‘mode of operation’ for the object the Statechart Diagramis considering
Massimo Felici State Machines c© 2004–2011
2
Activity vs. State Machines
• In UML semantics Activity Diagrams are reducible to State Machines withsome additional notations
• In Activity Diagrams the vertices represent the carrying out of an activityand the edges represent the transition on the completion of one collection ofactivities to the commencement of a new collection of activities
• Activity Diagrams capture high level activities aspects
• In State Machines the vertices represent states of an object in a class andedges represent occurrences of events
Massimo Felici State Machines c© 2004–2011
Example 3
State Machines
A state machine diagram for invoices
Massimo Felici State Machines c© 2004–2011
Basics 4
State Machines
• Simple• Complex States
– Composite and Submachine States– Concurrent Substates– History States– Synch States
• Transitions• Synchronisation Bars and Decision Points• Transition types• Transitions to/from Composite States• Actions
Massimo Felici State Machines c© 2004–2011
5
Events
• Internal or External Events trigger some activity that changes the state of thesystem and of some of its parts
• Events pass information, which is elaborated by Objects operations. Objectsrealise Events
• Design involves examining events in a State Machine and considering howthose events will be supported by system objects
Massimo Felici State Machines c© 2004–2011
6
States
• A state is a condition of being at a certain time
• Objects (or Systems) can be viewed as moving from state to state
• A point in the lifecycle of a model element that satisfies some condition, wheresome particular action is being performed or where some event is waited
• Start and End States
Massimo Felici State Machines c© 2004–2011
Example 7
State Machines
A state machine diagram for a lift
Massimo Felici State Machines c© 2004–2011
8
Actions
• States can trigger actions
• States can have a second compartment that contains actions or activitiesperformed while an entity is in a given state
• An action is an atomic execution and therefore completes without interruption
• Five triggers for actions: On Entry, Do, On Event, On Exit, and Include
• An activity captures complex behaviour that may run for a long duration – Anactivity may be interrupted by events, in which case it does not complete
Massimo Felici State Machines c© 2004–2011
Example 9
State Machines
• A state called Login
• Actions are performed on entry, on exit and while in the state.
Massimo Felici State Machines c© 2004–2011
10
Simple and Composite States
• Simple States – simplest of all states, they have no substates
• Composite States - have one or more regions for substates
• Submachine States - semantically equivalent to composite states, submachinestates have substates that are contained within a substate machine
• An History State – indicated by a circle with an H inside it – allows there-entering of a composite state at the point which it was last left
Massimo Felici State Machines c© 2004–2011
11
Concurrent Substates and Regions
• Concurrent Substates are independent and can complete at different times
• Each substate is separated from the others by a dashed line
Massimo Felici State Machines c© 2004–2011
Example 12
State Machines
Superstate with nested substates
Massimo Felici State Machines c© 2004–2011
Example – Concurrent orthogonal states 13
State Machines
Massimo Felici State Machines c© 2004–2011
14
Transitions
• Viewing a system as a set of states and transitions between states is very usefulfor describing complex behaviors
• Understanding state transitions is part of system analysis and design• A Transition is the movement from one state to another state• Transitions between states occur as follows:
1. An element is in a source state2. An event occurs3. An action is performed4. The element enters a target state
• Multiple transitions occur either when different events result in a stateterminating or when there are guard conditions on the transitions
• A transition without an event and action is known as automatic transitions
Massimo Felici State Machines c© 2004–2011
Types 15
Transitions
Compound Transition - A representation of the change from one completestate machine configuration to another.
High-level Transition - A transition from a composite state.
Internal Transition - A transition between states within the same compositestate. Note that transitions between regions of the same composite state arenot allowed.
Completion Transition - A transition from a state that has no explicit trigger.
Massimo Felici State Machines c© 2004–2011
16
Synchronisation Bars and Decision Points
Synchronisation Bars
• Allow the representation of concurrent states• Let transitions to split or combine• It is important when the overall state of a class is split into concurrent states
that these states are re-combined on the same diagram
Decision Points
• Let a transition to split along a number of transitions based on a condition
Massimo Felici State Machines c© 2004–2011
17
Transitions to/from Composite States
• To composite states boundary
– start the subflow at the initial state of the composite state– If the composite state is concurrent, then the transition is to each of the
initial states
• From composite states boundary
– Immediate and effective on any of the substates
• To the substates
• From substates out to other states
Massimo Felici State Machines c© 2004–2011
18
Designing Classes with States Diagrams
• Keep the state diagram simple
– State diagrams can very quickly become extremely complex and confusing– At all time, you should follow the aesthetic rule: ‘Less is More’
• If the state diagram gets too complex consider splitting it into smaller classes
• Document states thoroughly
• Check consistency with the other view of the dynamics
• Think about compound state changes in a collaboration or sequence
Massimo Felici State Machines c© 2004–2011
19
Building Statechart Diagrams
1. Identify entities that have complex behaviour – Identify a class participating inbehaviour whose lifecycle is to be specified
2. Model states – Determine the initial and final states of the entity3. Model transitions4. Model events – Identify the events that affect the entity5. Working from the initial state, trace the impact of events and identify
intermediate states6. Identify any entry and exit actions on the states7. Expand states using substates where necessary8. If the entity is a class, check that the action in the state are supported by the
operations and relationships of the class, and if not extend the class9. Refine and elaborate as required
Massimo Felici State Machines c© 2004–2011
Example – A Simple Microwave Oven 20
State Machines
1. Select the power level
2. Input the cooking time
3. Press start
4. Safety: the oven should never operate when the door is open
Massimo Felici State Machines c© 2004–2011
Example – A Simple Microwave Oven 21
State Machines
Massimo Felici State Machines c© 2004–2011
22
Types of State Machines
Behavioural state machines show the behavior of model elements such asobjects. A behavioural state machine represents a specific implementation ofan element.
Protocol state machines show the bahavior of a protocol. They show howparticipants may trigger changes in a protocols state and the correspondingchanges in the system.
Massimo Felici State Machines c© 2004–2011
23
Some (Open) Questions
• What are the benefits of having states in a system?• What are the costs of having states in a system?• Every state should have an edge for every message in the class – is this the
right view?• How does this description of state relate to design by contract?• How would you check that a Java implementation was consistent with a state
diagram?• How does this differ with the treatment of state in programming languages?• What does this say about the different between modeling and programming?
Massimo Felici State Machines c© 2004–2011
24
Readings
Required Readings
• UML course textbook, Chapter 12 on State Machines
Suggested Readings
• D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science ofComputer Programming, Elsevier, 8(3):231-274, 1987.
• D. Harel. Statecharts in the making: a personal account. Communications ofthe ACM, 52(3):67-75, 2009.
Massimo Felici State Machines c© 2004–2011
25
Summary
• Statechart Diagrams
• Activity vs. Statechart Diagrams
• Statechart Diagrams Basics
States and Events, Transitions, Actions, Synchronisation Bars, Decision Points,Complex States (i.e., Composite States, Concurrent Substates, History States,Synch States)
• Building Statechart Diagrams
Massimo Felici State Machines c© 2004–2011
Software Testing
Massimo Felici
Massimo Felici Software Testing c© 2004–2011
1
What is Software Testing?Software Testing is the design and implementation of a special kind of softwaresystem: one that exercises another software system with the intent of findingbugs
Massimo Felici Software Testing c© 2004–2011
Slide 1: What is Software Testing?
Testing software typically involves
• Executing software with inputs representative of actual operation conditions(or operational profiles)
• Comparing produced/expected outputs
• Comparing resulting/expected states
• Measuring execution characteristics (e.g., memory used, time consumed, etc.)
Slide 1: What software testing is not...
• Model verification (e.g., by simulation)
• Tool-based static code analysis
• Human documentation/code scrutiny (inspection)
• Debugging: Testing is NOT debugging, and debugging is NOT testing
2
Terminology
• Fault: an imperfection that may lead to a failure
E.g., missing/incorrect code that may result in a failure
Bug: another name for a fault in code
• Error: where the system state is incorrect but may not have been observed
• Failure: some failure to deliver the expected service that is observable to theuser
Massimo Felici Software Testing c© 2004–2011
Slide 2: A few more definitions
• Test Case: set of inputs, execution conditions, and expected results developedfor a particular objective• Test Suite: collection of test cases, typically related by a testing goal or an
implementation dependency• Test Driver: class or utility program that applies test cases• Test harness: system of test drivers and other tools that support test execution• Test Strategy: algorithm or heuristic to create test cases from a
representation, implementation, or a test model• Oracle: means to check the output from a program is correct for the given
input• Stub: partial temporary implementation of a component (usually required for
a component to operate)
3
Testing Goals
• Validation testing
– To demonstrate to the developer and the system customer that the softwaremeets its requirements
– A successful test shows that the system operates as intended
• Defect testing
– To discover faults or defects in the software where its behaviour is incorrector not in conformance with its specification
– A successful test is a test that makes the system perform incorrectly and soexposes a defect in the system
Massimo Felici Software Testing c© 2004–2011
4
Effectiveness vs. Efficiency
• Test Effectiveness
Relative ability of testing strategy to find bugs in the software
• Test Efficiency
Relative cost of finding a bug in the software under test
Massimo Felici Software Testing c© 2004–2011
5
What is a successful test?
• Pass
Status of a completed test case whose actual results are the same as theexpected results
• No Pass
Status of a completed software test case whose actual results differ from theexpected ones – “Successful” test (i.e., we want this to happen)
Massimo Felici Software Testing c© 2004–2011
6
Software Testing Features
• The scope of testing
The different levels of the system that testing addresses
• Test techniques
Some of the approaches to building and applying tests
• Test management
How we manage the testing process to maximise the effectiveness and efficiencyof the process for a given product
Massimo Felici Software Testing c© 2004–2011
7
Testing scope
• Testing in the small – unit testing
Exercising the smallest executable units of the system
• Testing the build – integration testing
Finding problems in the interaction between components
• Testing in the large – system testing
Putting the entire system to test
Massimo Felici Software Testing c© 2004–2011
8
Testing Categorization
• Fault-directed testing
– Unit testing– Integration testing
• Conformance-directed testing
– System testing– Acceptance testing
Massimo Felici Software Testing c© 2004–2011
9
Testing “in the small”
• Unit Testing– Exercising the smallest individually executable code units– Component or unit testing is the process of testing individual components
in isolation – It is a defect testing process• Components may be
– Individual functions or methods within an object– Object classes with several attributes and methods– Composite components with defined interfaces used to access their
functionality• Objectives
– Finding faults– Assure correct functional behaviour of units
• Usually performed by programmers
Massimo Felici Software Testing c© 2004–2011
10
Object Class Testing
• Complete test coverage of a class involves
– Testing all operations associated with an object– Setting and interrogating all object attributes– Exercising the object in all possible states
• Inheritance makes it more difficult to design object class tests as the informationto be tested is not localised
Massimo Felici Software Testing c© 2004–2011
Example 11
Object Class Testing
• Need to define test cases for:
reportWeather, calibrate, test, startup and shutdown
• Using a state model, identify sequences of state transitions to be tested andthe event sequences to cause these transitions, for example:
Waiting → Calibrating → Testing → Transmitting → Waiting
Massimo Felici Software Testing c© 2004–2011
12
Interface Testing
• Objectives are to detect faults due to interface errors or invalid assumptionsabout interfaces
• Particularly important for object-oriented development as objects are definedby their interfaces
Massimo Felici Software Testing c© 2004–2011
Slide 12: Interface Types
• Parameter interfaces – Data passed from one procedure to another
• Shared memory interfaces – Block of memory is shared between proceduresor functions
• Procedural interfaces – Sub-system encapsulates a set of procedures to becalled by other sub-systems
• Message passing interfaces – Sub-systems request services from other sub-systems
13
Interface Errors
• Interface misuse – A calling component calls another component and makesan error in its use of its interface, e.g., parameters in the wrong order
• Interface misunderstanding – A calling component embeds assumptionsabout the behaviour of the called component which are incorrect
• Timing errors – The called and the calling component operate at differentspeeds and out-of-date information is accessed
Massimo Felici Software Testing c© 2004–2011
14
Testing the “build”
• Integration Testing– Exercising two or more units or components
• Objectives– Detect interface errors– Assure the functionality of the combined units
• Performed by programmers or testing group• Issues
– Strategy for combining units?– Compatibility with third-party components, e.g., COTS (Commercial Of
The Shelf) components?– Correctness of third-party components?
Massimo Felici Software Testing c© 2004–2011
15
Integration Testing
• Involves building a system from its components and testing it for problemsthat arise from component interactions.
• Top-down integration
Develop the skeleton of the system and populate it with components.
• Bottom-up integration
Integrate infrastructure components then add functional components.
• To simplify error localisation, systems should be incrementally integrated.
Massimo Felici Software Testing c© 2004–2011
Slide 15: Integration Testing
16
Testing “in the large”: System
• System Testing
– Exercising the functionality, performance, reliability, and security of theentire system
• Objectives
– Find errors in the overall system behaviour– Establish confidence in system functionality– Validate non-functional system requirements
• Usually performed by a separate testing group
Massimo Felici Software Testing c© 2004–2011
17
Testing “in the large”: Accept
• Acceptance Testing
– Operating the system in the user environment with standard user inputscenario
• Objectives
– Evaluate whether the system meets the customer criteria– Determine whether the customer will accept the system
• Usually performed by the end user
Massimo Felici Software Testing c© 2004–2011
18
Testing “in the large”: Operation
• Regression Testing
– Testing modified versions of a previously validated system
• Objectives
– Assuring that changes to the system have not introduced new errors
• Performed by the system itself or by a regression test group
• Capture/Replay (CR) Tools
Massimo Felici Software Testing c© 2004–2011
19
Test Generation Methods
• Black-box testing
– No knowledge of the software structure– Also called specification-based or functional testing
• White-box testing
– Knowledge of the software structure and implementation– White-box methods can be used for test generation and test adequacy
analysis– Usually used as adequacy criteria (after generation by a black-box method)– Methods based on internal code structure: Statement, Branch, Path or
Data-flow coverage
Massimo Felici Software Testing c© 2004–2011
Slide 19: Black-box Testing
20
Test Generation Methods
• Fault-based testing
– Objective is to find faults in the software, e.g., Unit testing
• Model-based testing
– Use of a data or behaviour model of the software, e.g., finite state machine
• Random testing
Massimo Felici Software Testing c© 2004–2011
21
Structural Testing
• Statement Testing: requires that every statement in the program be executed• Branch Testing: seeks to ensure that every branch has been executed
– Branch coverage can be checked by probes inserted at the points in theprogram that represent arcs from branch points in the flowgraph
– This instrumentation suffices for statement coverage as well• Expression Testing: requires that every expression assume a variety of valued
during a test in such a way that no expression can be replaced by a simplerexpression and still pass the test– Expression testing does require significant runtime support for the
instrumentation• Path Testing: data is selected to ensure that all paths of the program have
been executed– In practice, path coverage is impossible to achieve
Massimo Felici Software Testing c© 2004–2011
22
Issues with Structural Testing
• Is code coverage effective at detecting faults?
• How much coverage is enough?
• Is one coverage criterion better than another?
• Is coverage testing more effective that random test case selection?
Massimo Felici Software Testing c© 2004–2011
Slide 22: Experimental Results
• Experiment
– Black-box generation followed by white-box coverage-based testing
• Results
– High coverage alone does not guarantee fault detection– Fault detection increases significantly as coverage goes above 95– No significant difference between branch and Data-flow (expression)
coverage– Both Branch and Data-flow coverage are significantly more effective that
random test cases
23
Test Management
• Attitude to testing
• Effective documentation and control of the whole test process
• Documentation of tests and control of the test codebase
• Independence of test activities
• Costing and estimation of test activities
• Termination: deciding when to stop
• Managing effective reuse
Massimo Felici Software Testing c© 2004–2011
Activities 24
Test Management
• Test Planning
• Test case generation - can involve massive amounts of data for some systems
• Test environment development
• Execution of tests
• Evaluating test results
• Problem reporting
• Defect tracking
Massimo Felici Software Testing c© 2004–2011
From Use Cases to Test Cases
Massimo Felici
Massimo Felici From Use Cases to Test Cases c© 2004–2011
26
A (Black-box) Testers Viewpoint
• What is the system supposed to do?
• What are the things that can go wrong?
• How can I create and record a set of testing scenarios?
• How will I know when to stop testing?
• Is there anything else the system is supposed to do?
Massimo Felici From Use Cases to Test Cases c© 2004–2011
27
From Use Cases to Test cases
• One of the greatest benefits of use cases is that they provide a set of assetsthat can be used to drive the testing process
• Use cases can directly drive, or seed, the development of test cases
• The scenarios of a use case create templates for individual test cases
• Adding data values completes the test cases
• Testing non-functional requirement completes the testing process
Massimo Felici From Use Cases to Test Cases c© 2004–2011
Slide 27: From Use Cases to Test cases
• A comprehensive set of use cases that documents an ordered sequence ofevents describing how the system interacts with the user and how it deliversits results to that user
• A use case model that documents all the use cases for the system, as well ashow they interact and what actors drive them
• Within each use case, both a basic flow of events and a series of alternativeflows that defines what the system does in various what if scenarios
• Descriptions of pre-conditions and post-conditions
• A supplementary specification that defines the non-function requirements ofthe system
28
Deriving Test Cases from Use Cases
1. Identify the use-case scenarios
2. For each scenario, identify one or more test cases
3. For each test case, identify the conditions that will cause it to execute
4. Complete the test case by adding data values
Massimo Felici From Use Cases to Test Cases c© 2004–2011
29
Managing Test Coverage
• Select the most appropriate or critical use cases for the most thorough testing
– Often these use cases are primary user interfaces, are architecturallysignificant, or present a hazard or hardship of some kind to the usershould a defect remain undiscovered
• Chose each use case to test based on a balance between cost, risk, andnecessity of verifying the use case
• Determine the relative importance of your use cases by using priorities specificto your context
Massimo Felici From Use Cases to Test Cases c© 2004–2011
30
Black-box vs. White-box Testing
• For every use case, there is a use case realisation that represents how thesystem is designed to accomplish the use case• The use case itself lives in the requirements domain and simply specify necessary
behaviour• The use-case realisation lives inside the solution space and describes how the
behaviour is accomplished by the system
Massimo Felici From Use Cases to Test Cases c© 2004–2011
Example 31
Use Case-based Testing
• Use cases can be a basis for deriving the tests for a system – help identifyoperations to be tested and help design the required test cases• From an associated sequence diagram, the inputs and outputs to be created
for the tests can be identified
Massimo Felici From Use Cases to Test Cases c© 2004–2011
32
Is a Use Case a Test Case?
• NO• Test Cases
– Test cases form the foundation on which to design and develop testprocedures
– The ‘depth’ of the testing activity is proportional to the number of testcases
– The scale of the test effort is proportional to the number of use cases– Test design and development, and the resources needed, are largely governed
by the required test cases• Use-case Scenarios
– A scenario, or an instance of a use case, is a use-case execution wherein aspecific user executes the use case in a specific way
Massimo Felici From Use Cases to Test Cases c© 2004–2011
33
Scenarios for a use case
Massimo Felici From Use Cases to Test Cases c© 2004–2011
34
Relationships among test artifacts
Massimo Felici From Use Cases to Test Cases c© 2004–2011
Slide 34: Relationships among test artifacts
Test plan: contains information about the purpose and goals of testing withinthe project. Additionally, the test plan identifies the strategies to be used toimplement and execute testing and the resources needed.
Test case: is a set of test inputs, execution conditions, and expected resultsdeveloped for a particular objective, such as to exercise a particular programpath or to verify compliance with a specific requirement.
Test procedure: is a set of detailed instructions for the setup, execution, andevaluation of results for a given test case.
Test script: is a software script that automates the execution of a test procedure(or a portion of a test procedure).
Test coverage: defines the degree to which a given test or set of tests addressesall specified test cases for a given system or component.
Test item: is a build that is an object of testing.Test results: are a repository of data captured during the execution of a test
used in calculating the different key measures of testing.
35
A Matrix for Testing Specific ScenariosTestCaseID
Scenario /Condition
Description DataValue1
... DataValueN
ExpectedResult
ActualResult
1 Scenario 1
2 Scenario 2 A
3 Scenario 2 AA... ...
Massimo Felici From Use Cases to Test Cases c© 2004–2011
36
Readings
Required Readings
• J.A. Whittaker. What is Software Testing? And Why is it so Hard?. IEEESoftware, 17(1):70-79, January/February, 2000.
• P.C. Jorgensen, C. Erickson. Object Oriented Integration Testing.Communications of the ACM, 37(9):30-38, September, 1994.
Massimo Felici From Use Cases to Test Cases c© 2004–2011
37
Summary
• Testing is a critical part of the development of any system
• Testing can be carried out at a number of levels and is planned as an integralpart of the development process
• There is a wide range of approaches to test case generation and evolution ofthe adequacy of a test suite
• Test needs to be managed effectively if it is to be efficient
Massimo Felici From Use Cases to Test Cases c© 2004–2011
Deployment Diagrams
Massimo Felici
Massimo Felici Deployment Diagrams c© 2004–2011
1
Deployment Diagrams
• What existing systems will system need to interact or integrate with?• How robust does system need to be (e.g., redundant hardware in case of a
system failure)?• What and who will connect to or interact with system, and how will they do
it?• What middleware, including the operating system and communications
approaches and protocols, will system use?• What hardware and software will users directly interact with (PCs, network
computers, browsers, etc.)?• How will you monitor the system once deployed?• How secure does the system need to be (needs a firewall, physically secure
hardware, etc.)?
Massimo Felici Deployment Diagrams c© 2004–2011
Slide 1: When to Use Deployment Diagrams
• They are very handy in showing what is deployed where, so any nontrivialdeployment can make good use of them.
2
Deployment Diagrams
• Show the structure of the run-time system
• Capture the hardware that will be used to implement the system and the linksbetween different items of hardware
• Model physical hardware elements and the communication paths between them
• Plan the architecture of a system
• Document the deployment of software components or nodes
Massimo Felici Deployment Diagrams c© 2004–2011
Slide 2: Deployment Diagrams
• A Deployment Diagram shows the configuration of run-time processingelements and the software components, processes, and objects
• Software component instances represent run-time manifestations of code units
• Deployment Diagrams capture only components that exist as run-time entities
• A deployment diagram shows the systems hardware, the software installedon that hardware, and the middleware that connects the disparate machinestogether
• A Deployment Diagram is a collection of one or more deployment diagramswith their associated documentation
• Deployment diagrams show the physical configurations of software andhardware
Notation 3
Deployment Diagrams
Communication Path
Massimo Felici Deployment Diagrams c© 2004–2011
4
Communication AssociationA communication associations between nodes indicates a communication pathbetween the nodes that allows components on the nodes to communicate withone another
Massimo Felici Deployment Diagrams c© 2004–2011
5
Deployment Planning
• How will your system be installed?
• If different versions of the system will be in production at the same time, howwill you resolve differences?
• What physical sites do you need to deploy to and in what order?
• How will you train your users?
Massimo Felici Deployment Diagrams c© 2004–2011
Slide 5: Deployment Planning
• How will your system be installed?
– Who will install it? How long should it take to install?– Where the installation possibly fail? How do you back out if the installation
fails? How long does it take to back out?– What is your installation window (during what time period can you install
your system)?– What backups do you need before installation? Do you need to do a data
conversion?– How do you know that the installation was successful?
• If different versions of the system will be in production at the same time, howwill you resolve differences?
Slide 5: Deployment Planning
• What physical sites do you need to deploy to and in what order?
– How will you train your support and operations staff?– Do you need to deploy a production support system so that the support
staff uses their own environment to simulate problems?
• How will you train your users?
– What documentation, and in what formats and languages, do your users,and support and operation staff need?
– How will updates to documentation be deployed?
6
How to Produce Deployment Diagrams
1. Decide on the purpose of the diagram
2. Add nodes to the diagram
3. Add communication associations to the diagram
4. Add other elements to the diagram, such as components or active objects, ifrequired
5. Add dependencies between components and objects, if required
Massimo Felici Deployment Diagrams c© 2004–2011
Slide 6: Allocating Artifacts to Nodes
Consider a number of aspects when allocating components to nodes, e.g.:
• Resource usage
• Geographical location
• Access to devices
• Security
• Performance
• Extensibility and portability
7
Modelling Business Process
• Business modelling using nodes and components is an effective means ofcapturing non-computer based processes and entities
• This can be done very early in development, to complement the use case modeland other business modelling
• Components are the business procedures and documents; the nodes (“run-timestructure”) are the organisation units and resources (human and other) of thebusiness
Massimo Felici Deployment Diagrams c© 2004–2011
Example 8
Modelling Business Process
Massimo Felici Deployment Diagrams c© 2004–2011
9
Readings
Required Readings
• UML course textbook, Chapter 14 on Deployment Diagrams
Massimo Felici Deployment Diagrams c© 2004–2011
10
Summary
• Deployment Diagrams
– Rationale– Notation
• How to produce Deployment Diagrams
Massimo Felici Deployment Diagrams c© 2004–2011
Software Engineeringwith Objects and Components
Open Issues and Course Summary
Massimo Felici
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
1
Software Engineering with Objects andComponents
• Software development process– Lifecycle models and main stages– Process management– Testing– Maintenance and Evolution
• Introduction to UML Diagrams– Use cases– Class diagrams– CRC cards– Interaction diagrams– Activity and Statechart diagrams
• Reuse and components
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Open Questions 2
Software Engineering with Objects andComponents
• Is software engineering with objects and components a good way of buildingsystems?
• Why are we doing this? To build good systems
• What are good systems?
• Why do we need them?
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
3
Why a unified language?A unified language should be (and UML is?)
• Expressive
• Easy to use
• Unambiguous
• Tool supported
• Widely used
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Software Engineering with Objects and Components 4
Development Processes
• Development process– Architecture-centric and component-based– Iteration to control risk– Risk management is central
• (Unified?) design methodology– Pros: dependable, assessment, standards– Cons: constraints, overheads, generality– Unified modelling language combines pros while avoiding cons
• The unified process– Inception, Elaboration, Construction, Transition– There are many other processes (e.g., Spiral, Extreme Programming, etc.)
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
History 5
UML
• 1989-1994 OO “method wars”• 1994-1995 three Amigos and birth of UML• Oct 1996 feedback invited on UML 0.9• Jan 1997 UML 1.0 submitted as RFP (Request for Proposal) to OMG (Object
Management Group)• Jun 1999 UML 1.3 released• Sep 2000 (some UML 2.0 RFPs submitted• Feb 2001 UML 1.4 draft specification released• UML 1.5;• Current Version: UML 2.0. adopted in late 2003
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Open Issues 6
UML
• UML semantics
• Tool support
• OCL (Object Constraint Language)
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
What’s new in UML 2.0 7
UML
• Nested Classifiers: In UML, almost every model building block you workwith (classes, objects, components, behaviours such as activities and statemachines, and more) is a classifier. In UML 2.0, you can nest a set of classesinside the component that manages them, or embed a behavior (such as astate machine) inside the class or component that implements it.
• Improved Behavioural Modeling: In UML 1.X, the different behaviouralmodels were independent, but in UML 2.0, they all derive from a fundamentaldefinition of a behaviour (except for the Use Case, which is subtly differentbut still participates in the new organisation).
• Improved relationship between Structural and Behavioural Models: UML2.0 lets you designate that a behaviour represented by (for example) a StateMachine or Sequence Diagram is the behaviour of a class or a component.
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
8
Requirements Capture
• Users have different potentially conflicting views of the system
• Users usually fail to express requirements clearly – missing information,superfluous and redundant information, inaccurate information
• Users are poor at imagining what a system will be like
• Identifying all the work needing support by the system is difficult
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
9
Static Structures
• Desirable to build system quickly and cheaply
• Desirable to make system easy to maintain and modify
• Identifying classes: Data driven design, Responsibility driven design, Use casedriven design, Design by contract
• Class diagrams document: classes (attributes, operations) and associations(multiplicities, generalisations)
• System is some collection of objects in class model
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
10
Validating the Class Model
• CRC Cards: class, responsibility and collaborators
• UML interaction diagrams
• CRC cards and quality: Too many responsibilities implies low cohesion, Toomany collaborators implies high coupling
• CRC cards used to: Validate class model using role play, Record changes,Identify opportunities to refactor
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
11
Interactions
• Sequence and Communication diagrams – documents how classes realise usecases, thus, help to validate design
• Other uses: design patterns, component use, packages• Instance versus generic• Procedural versus concurrent• Law of Demeter• Creation and deletion of objects• timing
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Other UML Diagrams 12
UML
• Describing object behaviour
– Activity diagrams– State diagrams
• Implementation diagrams
– Package Diagrams– Composite Structures– Component Diagrams– Deployment Diagrams
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Other Software Engineering Issues 13
Testing
• Testing strategies: top-down versus bottom-up, black-box versus glass-box,stress testing
• Categories (unit, integration, acceptance)
• Regression testing
• Test plans
• OO and component issues
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Other Software Engineering Issues 14
Reuse and Components
• Type of reuse: Knowledge (artefacts, patterns), software (code, inheritance,template, component, framework)
• success stories, pitfalls and difficulties with (component) reuse
• Reuse not free and requires management
Massimo Felici Software Engineering with Objects and Components c© 2004–2011
Lecture Notes, Practicals and Resources 15
Software Engineering with Objects andComponents
• Lecture Notes– 14 Lecture Notes– Coursework drawn from an Industry Case Study
• Practicals– Requirements gathering, UML Design and Java Implementation– Group project– Different teams in each tutorial group– Tutorials
• Resources– References complementing and extending lecture notes– Main Tools: Eclipse or NetBeans, and UML plugin
Massimo Felici Software Engineering with Objects and Components c© 2004–2011