Lecture 1
SOFTWARE DEVELOPMENT
PB007 Software Engineering I
Faculty of Informatics, Masaryk University
Fall 2015
1© Barbora Bühnová
Outline
 Course organization
 Software development
 UML in software development
 UML Use Case diagram
2
Course Organization
Lecture 1/Part 1
3
About the lecturer:
Ing. RNDr. Barbora Bühnová, Ph.D.
 Industrial experience
 Research
 Quality of software architecture
 Lab of Software Architecture and Information Systems (LaSArIS)
 Teaching
 Courses on UML, software quality, architecture design,
programming, algorithm design, and others
 Collaboration with students
 Bachelor/Master theses (Honeywell, Siemens)
 Seminar tutoring
4
About the course:
PB007 Software Engineering I
 Lectures
1. Software development, UML Use Case diagram.
2. Requirements specification, UML Activity diagram.
3. System analysis and design, structured vs. object-oriented A&D.
4. Object oriented analysis, UML Class, Object and State diagram.
5. Structured analysis, data modelling, ERD.
6. High-level design, UML Class diagram in design.
7. Low-level design and implementation, UML Interaction diagrams
8. Architecture design, UML Package, Component and Deployment diagram.
9. Testing, verification and validation.
10. Operation, maintenance and system evolution.
11. Software development management.
12. Advanced software engineering techniques.
5
About the course:
PB007 Software Engineering I
 Seminars
1. Visual Paradigm introduction, project assignment.
2. Project start, initial Use Case diagram.
3. Detailed Use Case diagram, textual specification of UC
4. Specification of use cases, Activity diagram.
5. Analytical Class diagram, Object diagram.
6. Analytical Class diagram, update of UC diagram, interaction of objects.
7. State diagram.
8. Data modelling, Entity Relationship diagram.
9. Design-level Class diagram, interfaces, implementation details.
10. Refinement of use cases with Interaction diagrams.
11. Finalization of Interaction diagrams, Class diagram update.
12. Packages, Component diagram, Deployment diagram.
6
About the course:
PB007 Software Engineering I
 Prerequisites
 Basic knowledge of object oriented programming
 Lectures
 12 teaching weeks + 1 week free (28. 9. 2015)
 Seminars
 12 teaching weeks
 Team project on UML modeling, teams of 3 students (or less)
 Obligatory attendance (one absence ok) and weekly task delivery
 Simple test at the beginning of each seminar (starting in Week 03)
 Penalty for extra absence (-5 points) and late task delivery (-5 points)
 Evaluation
 Seminar = project YES/NO, tests (20 points) and penalty recorded in IS notebook
 Exam = test (35 points) + on-site modelling (35 points)
 Grades: F<50, 50<=E<58, 58<=D<66, 66<=C<74, 74<=B<82, 82<=A
7
Literature
 Software Engineering, 9/E
 Author: Ian Sommerville
 Publisher: Addison-Wesley
 Copyright: 2011
 UML 2 and the Unified Process, 2/E
 Author: Jim Arlow and Ila Neustadt
 Publisher: Addison-Wesley
 Copyright: 2005
8
Software Development
Lecture 1/Part 2
Chapter 2 Software Processes 9
Outline
 Software engineering
 Software process activities
 Software process models
Chapter 2 Software Processes 10
Software and system engineering
 The economies and human lifes of ALL developed
nations are dependent on software.
 Software engineering is concerned with theories,
methods and tools for professional software
development.
 Software engineering is concerned with cost-effective
development of high-quality software systems.
 System engineering is concerned with all aspects of
computer-based systems development including
hardware, software and process engineering.
Chapter 1 Introduction
Software products
 Generic products
 Stand-alone systems that are marketed and sold to any
customer who wishes to buy them.
 Examples – PC software such as graphics programs, project
management tools; CAD software.
 Customized products
 Software that is commissioned by a specific customer to meet
their own needs.
 Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
Chapter 1 Introduction 12
Application types
 Stand-alone desktop applications
 Interactive web-based applications
 Embedded control systems
 Batch processing systems
 Computer games
 Systems for modeling and simulation
 Data collection and monitoring systems
 Systems of systems
Chapter 1 Introduction 13
Software engineering fundamentals
 Some fundamental principles apply to all types of
software system, irrespective of the development
techniques used:
 Systems should be developed using a managed and
understood development process. Of course, different
processes are used for different types of software.
 Dependability and performance are important for all types of
system.
 Understanding and managing the software specification and
requirements (what the software should do) are important.
 Where appropriate, you should reuse software that has already
been developed rather than write new software.
Chapter 1 Introduction 14
The software process
 A structured set of activities required to develop a
software system.
 Many different software processes but all involve:
 Requirements specification
 Analysis and design
 Implementation
 Validation and verification
 Evolution
 Is the analysis and design always involved?
Chapter 2 Software Processes 15
Development
Software process activities
 Requirements specification, where customers and
engineers define the software and the constraints on its
operation.
 Analysis and design, where the requirements are refined
into system design.
 Implementation, where the software is implemented.
 Validation and verification, where the software is
checked to ensure that it is what the customer requires.
 Evolution, where the software is modified to reflect
changing customer and market requirements.
16Chapter 2 Software Processes
Software process models
Chapter 2 Software Processes 17
Agile
Early SCRUM
Agile Manifesto
Spiral
UML in Software Development
Lecture 1/Part 3
18Chapter 5 System modeling
System modeling
 System modeling is the process of developing abstract
models of a system, with each model presenting a
different view or perspective of that system.
 System modeling has now come to mean representing a
system using some kind of graphical notation, which is
now almost always based on notations in the Unified
Modeling Language (UML).
 System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with colleagues and customers.
Chapter 5 System modeling 19
System perspectives
 An external perspective, where you model system
boundary, the context and/or environment of the system.
 A structural perspective, where you model the
organization of a system or the structure of the data that
is processed by the system.
 An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
 A behavioral perspective, where you model the
dynamic behavior of the system and how it responds to
events.
Chapter 5 System modeling 20
UML diagram types
 External perspective
 Use case diagram
 Structural perspective
 Class diagram, Object diagram, Component diagram, Package
diagram, Deployment diagram, Composite structure diagram
 Interaction perspective
 Sequence diagram, Communication diagram, Interaction
overview diagram, Timing diagram
 Behavioral perspective
 Activity diagram, State diagram
Chapter 5 System modeling 21
Popular UML diagrams
 Use case diagrams, which show the interactions
between a system and its environment.
 Class diagrams, which show the object classes in
the system and the associations between these classes.
 Sequence diagrams, which show interactions between
actors and the system and between system components.
 Activity diagrams, which show the activities involved in a process
or in data processing.
Chapter 5 System modeling 22
UML Use Case Diagram
Lecture 1/Part 4
23Chapter 4 Requirements engineering
Outline
 Use Case modelling
 System boundary – subject
 Use cases
 Actors
 Textual Use Case specification
 Advanced Use Case modelling
 Actor generalisation
 Use case generalisation
 «include»
 «extend»
24Chapter 4 Requirements engineering
© Clear View Training 2010 v2.6 25
The purpose of Use Case modelling
 Software specification
 The process of identifying and establishing system requirements
 Often referred to as requirements specification or
requirements engineering
 Use case modelling proceeds as follows:
 Find the system boundary
 Find actors – who or what uses the system
 Find use cases – what functions the system should offer
 Specify use cases – with textual specification or UML Activity
Diagrams
© Clear View Training 2010 v2.6 26
The subject
 We create a Use Case model containing:
 Subject – the edge of the system
• also known as the system boundary
 Actors – who or what uses the system
 Use Cases – things actors do with the
system; functions the system should
offer to its users
 Relationships – between actors and
use cases
 Can there be a direct communication
relationship between actors?
SystemName
subject
© Clear View Training 2010 v2.6 27
What are actors?
 An actor is anything that interacts directly
with the system
 Actors identify who or what
uses the system and so indicate
where the system boundary lies
 Actors are external
to the system
 An Actor specifies a role that some external entity
adopts when interacting with the system
 Can one actor represent two physical persons?
 Can one physical person match to two actors?
 Can there be two actors with the same name in the model?
Customer
«actor»
Customer
© Clear View Training 2010 v2.6 28
Identifying Actors
 When identifying actors ask:
 Who or what uses the system?
 What roles do they play in the interaction?
 Who installs the system?
 Who starts and shuts down the system?
 Who maintains the system?
 What other systems use this system?
 Who gets and provides information to the system?
 Does anything happen at a fixed time?
 What if the actor is not a human? What can it be?
Time
© Clear View Training 2010 v2.6 29
What are use cases?
 A use case is something an actor needs the system to
do. It is a “case of use” of the system by a specific actor.
 Use cases are always started by an actor
 The primary actor triggers the use case
 Zero or more secondary actors interact with the use case in
some way
 Does the UC diagram tell me which actor is primary/secondary?
 Use cases are always written from the point of view of
the actors.
PlaceOrder GetStatusOnOrder
© Clear View Training 2010 v2.6 30
Identifying use cases
 Start with the list of actors that interact with the system
 When identifying use cases ask:
 What functions will a specific actor want from the system?
 Does the system store and retrieve information? If so, which
actors trigger this behaviour?
 What happens when the system changes state (e.g. system start
and stop)? Are any actors notified?
 Are there any external events that affect the system? What
notifies the system about those events?
 Does the system interact with any external system?
 Does the system generate any reports?
© Clear View Training 2010 v2.6 31
The use case diagram
Mail Order System
PlaceOrder
SendCatalogue
CancelOrder
CheckOrderStatusCustomer
ShipProduct
ShippingCompany
Dispatcher
communication
relationship
actor
subject name
system boundary
Mail Order System use case diagram
use case
© Clear View Training 2010 v2.6 32
Textual use case specification
Use case: PaySalesTax
Primary actors:
Time
Preconditions:
1. It is the end of the business quarter.
Postconditions:
1. The Tax Authority receives the correct amount of Sales Tax.
Main flow:
The use case starts when it is the end of the business quarter.
The system determines the amount of Sales Tax owed to the Tax
Authority.
The system sends an electronic payment to the Tax Authority.
1.
2.
3.
use case name
the actors involved in the
use case
the system state before
the use case can begin
the actual steps of the use
case
the system state when the
use case has finished
Alternative flows:
None.
alternative flows
ID: 1use case identifier
Brief description:
Pay Sales Tax to the Tax Authority at the end of the business quarter.
brief description
implicit time actor
Secondary actors:
TaxAuthority
© Clear View Training 2010 v2.6 33
Naming use cases
 Use cases describe something that happens
 They are named using verbs or verb phrases
 Naming standard 1: use cases are named using
UpperCamelCase e.g. PaySalesTax
1 UML 2 does not specify any naming standards.
All naming standards here are based on industry best practice.
© Clear View Training 2010 v2.6 34
Pre and postconditions
 Preconditions and postconditions
are constraints.
 Preconditions constrain the state
of the system before the use case
can start
 Postconditions constrain the state
of the system after the use case
has executed
 What pre/postconditions does a
delete of a product have?
 What about if the deletion is not
successful?
Preconditions:
1. A valid user has logged on to the
system
Postconditions:
1. The order has been marked
confirmed and is saved by the system
Use case: PlaceOrder
© Clear View Training 2010 v2.6 35
Main flow
 The flow of events lists the steps in a use case
 It always begins by an actor doing something
 A good way to start a flow of events is:
1) The use case starts when an <actor> <function>
 The flow of events should be a sequence of short steps that are:
 Declarative
 Numbered,
 Time ordered
 The main flow is always the happy day scenario
 Everything goes as expected, without errors, deviations and interrupts
 Alternatives can be shown by branching or by listing under Alternative
flows (see later)
<number> The <something> <some action>
© Clear View Training 2010 v2.6 36
Branching within a flow: IF
 Use the keyword IF to
indicate alternatives
within the flow of events
 There must be a
Boolean expression
immediately after IF
 Use indentation and
numbering to indicate
the conditional part of
the flow
 Use ELSE to indicate
what happens if the
condition is false
Use case: ManageBasket
Primary actors:
Customer
Preconditions:
1. The shopping basket contents are visible.
Postconditions:
None.
Main flow:
The use case starts when the Customer selects an item in the
basket.
IF the Customer selects "delete item"
IF the Customer types in a new quantity
1.
2.
3.
The system removes the item from the basket.2.1
The system updates the quantity of the item in the basket.3.1
ID: 2
Brief description:
The Customer changes the quantity of an item in the basket.
Alternative flows:
None.
Secondary actors:
None.
© Clear View Training 2010 v2.6 37
Repetition within a flow: FOR
 We can use the
keyword FOR to
indicate the start of a
repetition within the
flow of events
 The iteration
expression immediately
after the FOR
statement indicates the
number of repetitions of
the indented text
beneath the FOR
statement.
ID: 3
Actors:
Customer
Preconditions:
None.
Main flow:
1. The use case starts when the Customer selects "find product".
2. The system asks the Customer for search criteria.
3. The Customer enters the requested criteria.
4. The system searches for products that match the Customer's criteria.
5. FOR each product found
5.1. The system displays a thumbnail sketch of the product.
5.2. The system displays a summary of the product details.
5.3. The system displays the product price.
Postconditions:
None.
Alternative flows:
NoProductsFound
Use case: FindProduct
Brief description:
The system finds some products based on Customer search criteria and
displays them to the Customer.
© Clear View Training 2010 v2.6 38
Repetition within a flow: WHILE
 We can use the
keyword WHILE to
indicate that something
repeats while some
Boolean condition is
true
ID: 4
Primary actors:
Customer
Preconditions:
None.
Main flow:
1. The use case starts when the Customer selects "show company details".
2. The system displays a web page showing the company details.
3. WHILE the Customer is browsing the company details
4. The system searches for products that match the Customer's criteria.
4.1. The system plays some background music.
4.2. The system displays special offers in a banner ad.
Postconditions:
1. The system has displayed the company details.
2. The system has played some background music.
3. The systems has displayed special offers.
Alternative flows:
None.
Use case: ShowCompanyDetails
Brief description:
The system displays the company details to the Customer.
Secondary actors:
None
© Clear View Training 2010 v2.6 39
Branching: Alternative flows
 Alternative flows capture
errors, branches, and
interrupts
 They can often be
triggered at any time
during the main flow
 Alternative flows never
return to the main flow
main flow
alternative flows
Use case
Only document enough alternative flows to
clarify the requirements!
© Clear View Training 2010 v2.6 40
Referencing alternative flows
 List the names of the
alternative flows at the
end of the use case
 Find alternative flows
by examining each
step in the main flow
and looking for:
 Alternatives
 Exceptions
 Interrupts
Alternative
flows
Main flow:
Use case: CreateNewCustomerAccount
Preconditions:
None.
Brief description:
The system creates a new account for the Customer.
Postconditions:
1. A new account has been created for the Customer.
Alternative flows:
InvalidEmailAddress
InvalidPassword
Cancel
The use case begins when the Customer selects "create
new customer account".
WHILE the Customer details are invalid
The system creates a new account for the Customer.
The system asks the Customer to enter his or her details
comprising email address, password and password
again for confirmation.
The system validates the Customer details.
1.
2.
3.
2.1.
2.2
ID: 5
Primary actors:
Customer
Secondary actors:
None.
© Clear View Training 2010 v2.6 41
Advanced Use Case modelling
 We have studied basic use case analysis, but there are
relationships that we have still to explore:
 Actor generalisation
 Use case generalisation
 «include» – between use cases
 «extend» – between use cases
© Clear View Training 2010 v2.6 42
Actor generalization - example
 The Customer and the
Sales Agent actors are
very similar
 They both interact with
List products, Order
products, Accept
payment
 They both can play the
purchaser role.
Sales system
ListProducts
OrderProducts
AcceptPayment
CalculateCommission
Customer
SalesAgent
© Clear View Training 2010 v2.6 43
Actor generalisation
 If two actors share the same
sub-role, which makes them
communicate with the same
set of use cases
 The descendent actors inherit
the roles and relationships
to use cases held by the
ancestor actor
 We can substitute a
descendent actor anywhere
the ancestor actor is expected.
This is the substitutability
principle
 Is it always a good idea to
generalize two actors sharing
some use cases?
Sales system
ListProducts
OrderProducts
AcceptPayment
CalculateCommission
Purchaser
SalesAgentCustomer
ancestor
or parent
descendents or children
generalisation
abstract actor
Use actor generalization when it simplifies
the model
© Clear View Training 2010 v2.6 44
Use case generalisation
 The ancestor use case
must be a more general
case of one or more
descendant use cases
 Child use cases are more
specific forms of their
parent
 They can inherit, add and
override features of their
parent
Sales system
FindProduct
FindBook FindCD
Customer
© Clear View Training 2010 v2.6 45
«include»
 When use cases share
common behaviour we
can factor this out into
a separate inclusion use
case and «include» it in
base use cases
 Base use cases are
not complete without
the included use
cases
 Inclusion use cases may
be complete use cases,
or they may just specify a
fragment of behaviour
for inclusion elsewhere
Personnel System
FindEmployeeDetails
ChangeEmployeeDetails
DeleteEmployeeDetails
Manager
ViewEmployeeDetails
«include»
«include»
«include»
base use case
inclusion
use case
include
relationship
BA
«include»
© Clear View Training 2010 v2.6 46
«include» example
Use case: ChangeEmployeeDetails
Primary actors:
Manager
Preconditions:
1. The Manager is logged on to the system.
Postconditions:
1. The employee details have been changed.
Main flow:
include( FindEmployeeDetails ).
The system displays the employee details.
The Manager changes the employee
details.
1.
2.
3.
ID: 1
Brief description:
The Manager changes the employee details.
Alternative flows:
None.
Use case: FindEmployeeDetails
Primary actors:
Manager
Preconditions:
1. The Manager is logged on to the system.
Postconditions:
1. The system has found the employee details.
Main flow:
The Manager enters the employee's ID.
The system finds the employee details.
1.
2.
ID: 4
Brief description:
The Manager finds the employee details.
Alternative flows:
None.
Seconday actors:
None
Seconday actors:
None
© Clear View Training 2010 v2.6 47
«extend»
 The extension use case
inserts behaviour into the
base use case.
 The base use case provides
extension points, but does
not know about the
extensions.
 The base use case is
complete already without the
extensions.
 There may be multiple
extension points and multiple
extending use cases.
Library system
IssueFineBorrowBook
FindBook
Librarian
ReturnBook
«extend»
base use case
extend
relationship extension
use case
BA
«extend»
BA
«include»
© Clear View Training 2010 v2.6 48
<<extend>> example
 Extension points are not numbered,
as they are not part of the flow
Use case: ReturnBook
Secondary actors:
None.
Preconditions:
1. The Librarian is logged on to the system.
Postconditions:
1. The book has been returned.
Main flow:
The Librarian enters the borrower's ID number.
The system displays the borrower's details including the list of
borrowed books.
The Librarian finds the book to be returned in the list of books.
The Librarian returns the book.
…
1.
2.
3.
4.
ID: 9
Brief description:
The Librarian returns a borrowed book.
Alternative flows:
None.
ReturnBook
extension points
overdueBook
IssueFine
«extend»
(overdueBook)
extension point: overdueBook
extension
point
base use case
extension use case
extension
point name
Primary actors:
Librarian
© Clear View Training 2010 v2.6 49
Requirements tracing
There is a many-to-many relationship between
requirements and use cases:
 One use case covers many individual functional
requirements
 One functional requirement may be realised by
many use cases
 Requirements Traceability Matrix can help us
to trace if all requirements are covered by our
use case model
R1
R2
R3
R4
R5
U1 U2 U3 U4
Use cases
Requirements
Requirements
Traceability
Matrix
© Clear View Training 2010 v2.6 50
Key points
 Use cases describe system behaviour from the point of
view of actors. They are the best choice when:
 The system is dominated by functional requirements
 The system has many types of user to which it delivers different
functionality
 The system has many interfaces
 We have discussed:
 Actors, use cases and their textual specification
 Actor and use case generalization
 Advanced relationships between use cases (include, extend)
 Use advanced features only where they simplify the
model!