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

[email protected]


http://www.inf.ed.ac.uk/teaching/courses/seoc/

mailto:[email protected]


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


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.


Tutorials

• Tutorials begin in week 3

• Frequency once a week ; Maximum 12 people per tutorial group



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


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.



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.

http://dx.doi.org/10.1109/2.920608

http://dx.doi.org/10.1109/2.920608


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.

http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=4425811

http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=4425811

2

Some Aspects of Software Engineering

• Software Processes

• Software Process Models

• Software Engineering Methods

• Costs

• Software Attributes

• Tools

• Professional and Ethical Responsibilities



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.


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


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.

http://dx.doi.org/10.1109/MSPEC.2005.1502528

http://dx.doi.org/10.1109/MSPEC.2005.1502528

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.


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.

http://dx.doi.org/10.1109/TDSC.2004.2



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


Software Failures 2 6


• The London Ambulance fiasco

• Therac 25 and other medical device failures

– (Software) Reliability is different than (System) Safety



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.

http://dx.doi.org/10.1109/MS.1997.589224

http://dx.doi.org/10.1109/MS.1997.589224

http://dx.doi.org/10.1109/2.562936

http://dx.doi.org/10.1109/2.562936

http://dx.doi.org/10.1109/MC.2007.55

http://dx.doi.org/10.1109/MC.2007.55


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.

http://dx.doi.org/10.1109/MC.1993.274940

http://dx.doi.org/10.1109/MC.1993.274940

http://dx.doi.org/10.1109/HASE.1999.809487

http://dx.doi.org/10.1109/HASE.1999.809487

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.



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.



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



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.


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.



• 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


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


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


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


Capture how objects interact to achieve a goal

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.


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.


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


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


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.


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.



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.


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.

http://doi.ieeecomputersociety.org/10.1109/MS.2005.13

http://doi.ieeecomputersociety.org/10.1109/MS.2005.13

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


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: 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’



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


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


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


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.

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.

http://dx.doi.org/10.1109/52.754056

http://dx.doi.org/10.1109/52.754056

http://dx.doi.org/10.1109/52.754056

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



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


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



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.


Suggested Readings

• M. Jarke. Requirements Tracing. Communications of the ACM, Vol. 41, No.12, December 1998.

http://doi.acm.org/10.1145/290133.290145

http://doi.acm.org/10.1145/290133.290145


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


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


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


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.

http://dx.doi.org/10.1109/IEEESTD.1998.88286



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



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


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.


http://dx.doi.org/10.1109/MS.2005.13

http://dx.doi.org/10.1109/MS.2005.13



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.


http://doi.acm.org/10.1145/290133.290145

http://doi.acm.org/10.1145/290133.290145

http://dx.doi.org/10.1109/52.754056

http://dx.doi.org/10.1109/52.754056

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


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


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


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


4

Use Cases at a Glance

Generalization


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


Example 1 6



Example 2 7



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?


Example 3 9

Generalizations between Actors


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?


Example 4 11

Generalizations between Use CasesPayment, for instance, is a generalization of Payment by credit cards and paymentby cash


Example 5 12

<<include>> Relationship


Example 6 13

<<extend>> Relationship


Example 7 14

<<extend>> Relationship


Example 8 15

System Boundaries


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


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


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


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


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


Example 9 21

An ATM System


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


23

Required Readings

• UML course textbook, Chapter 3 on Use Cases


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


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


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?


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


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


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.


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


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


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


Basics 9

Class Diagrams

• Classes

– Basic Class Components– Attributes and Operations

• Class Relationships

– Associations– Generalizations– Aggregations and Compositions


Construction 10

Class DiagramsConstruction involves

1. Modelling classes

2. Modelling relationships between classes, and

3. Refining and elaborate as necessary


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


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


Example 13

Basic Class Compartments


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


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.


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


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


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


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


Examples 20

Dependency


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


Examples 22

Association


Example 23

Association


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


Example 25

Association Class


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


Example 27

Aggregation


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


Example 29

Composition


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


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”


Example1 32



Example2 33



Implementing Generalizations 34


• 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


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


Example 36

Abstract Classes


Example 37

Interface Classes


38

Template Classes


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


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


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


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


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.


http://doi.ieeecomputersociety.org/10.1109/52.469759

http://doi.ieeecomputersociety.org/10.1109/52.469759

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.


http://dx.doi.org/10.1109/MS.2006.59

http://dx.doi.org/10.1109/MS.2006.59

http://dx.doi.org/10.1109/2.161279

http://dx.doi.org/10.1109/2.161279

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


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


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


3

Benefits of Software Reuse

• Increased dependability

• Reduced process risk

• Effective use of specialists

• Standards compliance

• Accelerated development


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


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


6

Types of Reuse

• Reuse of Knowledge

– Artifact reuse– Pattern reuse

• Reuse of Software

– Code reuse– Inheritance reuse– Template reuse– Component reuse– Framework reuse


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)


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.


9

Documenting Patterns

• Pattern Name• Classification• Intent• Also Known As• Motivation (Forces)• Applicability• Structure• Participants• Collaborations• Consequences• Implementation• Sample Code• Known Uses• Related Patterns


Example of Creational Pattern 10

BuilderSeparate the construction of a complex object from its representation so thatthe same construction process can create different representations


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


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


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


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


Example of Behavioral Pattern 15

StateAllow an object to alter its behavior when its internal state changes. The objectwill appear to change its class


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


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?


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



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



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



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



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


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


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)


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.


http://dx.doi.org/10.1109/52.976942

http://dx.doi.org/10.1109/52.976942

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


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


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


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)


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


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


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


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


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


Example – Use Cases 9

A Library System


Example – Class Diagram 10

A Library System


Example – CRC Cards 11

A Library System


Example – A CRC Game 12

A Library System


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


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


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


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


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


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


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


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.


http://doi.acm.org/10.1145/74877.74879

http://doi.acm.org/10.1145/74877.74879

http://doi.acm.org/10.1145/74877.74879

http://dx.doi.org/10.1109/TSE.2004.1265817

http://dx.doi.org/10.1109/TSE.2004.1265817

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


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


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


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


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



• 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


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


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.


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.


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


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.


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


11

Required Readings

• UML course textbook, Chapter 7 on Class Diagram: Other Notations

• UML course textbook, Chapter 8 on Component Diagrams


12

Summary

• Component Rationale

• Notation

• Component Diagrams

• Modelling


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


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


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


Notations 4

Sequence Diagrams

• Frames• Lifelines• Messages and Focus Control• Combined Fragments• Interaction Occurrences• States• Continuations• Textual Annotation• Tabular Notation


5

Frames


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]


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


8

Messages and Focus of Control


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


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.


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.


Example 12

A sequence diagram for distributed control


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


Notation 14

Sequence Fragments


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.


Example 16

Interaction Frames


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


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.


Example 19

Timing


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


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.


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


23

Required Readings

• UML course textbook, Chapter 9 on Interaction Sequence Diagrams


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


Communication Diagrams

Massimo Felici

Massimo Felici Communication Diagrams c© 2004–2011

1

Realizing Use cases in the Design Model


Rationale 2


• 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


3


• 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


Example 4

Sequence and Communication Diagrams


What is a Collaboration? 5


• 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


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


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


Specification and Instance Levels 8


• 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


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


Simple Example 10



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.


12

Messages

Synchronous Asynchronous

Creation Reply


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.


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


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


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


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


18

Communication vs. Sequence Diagrams

Communication SequenceDiagrams Diagrams

Participants ! !

Links !

Message Signature ! !

Parallel Messages ! !

Asynchronous messages !

Message Ordering !

Create & Maintain !


19

Constructing Communication Diagrams

1. Identify behaviour

2. Identify the structural elements

3. Model structural relationships

4. Consider the alternative scenarios


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.


http://dx.doi.org/10.1109/52.35588

http://dx.doi.org/10.1109/52.35588

21

Summary


– Sequence Diagrams– Communication Diagrams

• Communication Diagrams Rationale

• Communication Diagrams

– Collaborations– Interactions– Messages

• Constructing Communication Diagrams


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


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


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


Example 4

Activity Diagram


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


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


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


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


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


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


Example 11

Flows and Edges


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


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.


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


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


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


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


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


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


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


Example 21

Signals on Activity Diagrams


Example 22

Sending and Receiving Signals


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


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


25

Readings

Required Readings

• UML course textbook, Chapter 11 on Activities


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


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


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


Example 3

State Machines

A state machine diagram for invoices


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


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


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


Example 7

State Machines

A state machine diagram for a lift


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


Example 9

State Machines

• A state called Login

• Actions are performed on entry, on exit and while in the state.


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


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


Example 12

State Machines

Superstate with nested substates


Example – Concurrent orthogonal states 13

State Machines


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


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.


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


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


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


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


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


Example – A Simple Microwave Oven 21

State Machines


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.


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?


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.


http://dx.doi.org/10.1016/0167-6423(87)90035-9

http://dx.doi.org/10.1016/0167-6423(87)90035-9

http://doi.acm.org/10.1145/1467247.1467274

http://doi.acm.org/10.1145/1467247.1467274

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


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


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

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


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


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


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)


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


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


8

Testing Categorization

• Fault-directed testing

– Unit testing– Integration testing

• Conformance-directed testing

– System testing– Acceptance testing


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


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


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


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


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


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?


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.


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


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


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


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


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


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


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?


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


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


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?


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


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


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


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


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


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


33

Scenarios for a use case


34

Relationships among test artifacts


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


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.


http://dx.doi.org/10.1109/52.819971

http://dx.doi.org/10.1109/52.819971

http://doi.acm.org/10.1145/182987.182989

http://doi.acm.org/10.1145/182987.182989

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


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


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


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


4

Communication AssociationA communication associations between nodes indicates a communication pathbetween the nodes that allows components on the nodes to communicate withone another


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?


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?

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


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


Example 8

Modelling Business Process


9

Readings

Required Readings

• UML course textbook, Chapter 14 on Deployment Diagrams


10

Summary

• Deployment Diagrams

– Rationale– Notation

• How to produce Deployment Diagrams


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


Open Questions 2


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


3

Why a unified language?A unified language should be (and UML is?)

• Expressive

• Easy to use

• Unambiguous

• Tool supported

• Widely used


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


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


Open Issues 6

UML

• UML semantics

• Tool support

• OCL (Object Constraint Language)


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.


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


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


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


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


Other UML Diagrams 12

UML

• Describing object behaviour

– Activity diagrams– State diagrams

• Implementation diagrams

– Package Diagrams– Composite Structures– Component Diagrams– Deployment Diagrams


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


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


Lecture Notes, Practicals and Resources 15


• 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


seoc 2004-2011

Documents