Software Engineering I SENG201
Lecture 3 – Software engineering activities (part 2)
February 23, 2022
Copyright By PowCoder代写 加微信 powcoder
Previous lecture
1. Software engineering processes
2. Requirements engineering – overview
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
UML (Unified Modeling Language) diagram types
UML (Unified Modeling Language) diagram types
UML (Unified Modeling Language) diagram types
Class Composite structure Component Deployment Object Package
State chart / machine Interaction
Sequence Communication Interaction overview Timing
Use tools such as Umbrello or ArgoUML
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
Remember from before
• Distinct types of activities, e.g.,
– Requirementsengineering
– Coding (“Java part” of course)
– Operation + maintenance
UML diagram type
Class Composite structure Component Deployment Object Package
State chart / machine Interaction
Sequence Communication Interaction overview Timing
Use case diagram
System boundary
Online travel agency
Search flight
Pay flight
Association
Capture functional requirements, not quality requirements Describe what is in the system and what is not
Use cases / use case diagrams
• Use cases
– Interactions between actors and system
Fast slide
– Phrased as “actions” starting with verb
– Substantial service provided to actors
– Common problem: too many use cases (solution: decompose diagram)
– Roles that user can play
• User: entities that use system
• External to system (may not always be human)
– Can be generalized
• Descendant inherits all use cases of ancestor
• Descendants have one more specific use cases
International student
<
Enrol in <
May describe conditional / optional behaviour of a base use case “Extra” behaviour can be placed in its own use case
Extending use case depends on the base use case
Base (extended) use case fully functional by itself
<
Enrol in <
• Extracts use case fragments that are used in multiple use cases
• Included use case should be referenced from more places
• Base use case is incomplete without the included use case
• Included use case can be use case in its own right
Complete example
Enrol in university
<
Perform security check
<
Enrol in seminar
Student management system
International student
Documenting (textual) use cases
• Start / end
– Pre- / post-conditions (where do we start, what do we want to achieve)
• Blue sky scenario / main success scenario – Normal behaviour
• Numbered list of steps (simple interactions between actor and system) • Alternative flow
– Variation
• Exceptional flow
– When an error occurs M. Fowler (2004). UML Distilled. Addison-
– Condition resulting in extension
– One separate list of steps per extension
Pay invoice
The customer has already received an invoice (delivered by another use case called “Invoice buyer”) and has also received the goods or services ordered.
The customer’s account has been charged with the amount stated on the invoice. The customer will have received loyalty points depending on the value of the purchase.
• Blue sky scenario (normal flow of events)
1. Customer checks invoice to pay if it is consistent with the original order.
2. The customer schedules the invoice for payment by the bank.
3. When the payment is due, the system checks to see if there is enough money in the customer’s account. If enough money is available, the transaction is made.
Alternative flow
– E.g., payment by credit card
1. Customer checks invoice to pay if it is consistent with the original order. 2. The customer selects credit card as the payment method.
3. The system checks the credit card information and obtains pre-approval. 4. One the day payment is due, the credit card is charged.
Exceptional flow
– E.g., empty account, credit card authorization failure
1. The customer is asked to select a different payment method.
Benefits of use cases
• Easy communication with non-technical stakeholders
• Force us to reason about the system and functionality
• Starting point for more detailed software requirements
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
Remember from before
• Distinct types of activities, e.g.,
– Requirementsengineering
– Coding (“Java part” of course)
– Operation + maintenance
Software design
• Abstracts software structure and behavior through models
– Software (development) elements + their relationships
– Bridges gap between requirements and code
• Two generic levels of abstraction
– Detailed design
• E.g., what classes, what algorithms, what variables, etc. – Architecturaldesign(impact“system-wide”properties)
• E.g., system structure and decomposition, client-server versus peer-to-peer
UML diagram type
Class Composite structure Component Deployment Object Package
State chart / machine Interaction
Sequence Communication Interaction overview Timing
What is a class, what is an object?
• Classes package together “data” and functionality
• Classes: structures to describe – properties (attributes, states), and
– behaviour
– ofsoftware“entities”
– derived from real-world concepts
• Objects are instances of a class Class
Object 1 Object 1 Object N
Real-world concepts
Example: class Student
Properties
Name = “Nancy”
Address = “Christchurch”
Current location = “In lecture room A2”
Name of class
Properties
Current location
Attend lecture Go home Sleep
Properties
Name = “Elora”
Address = “Auckland” Current location = “In bed”
Some properties can change
Properties
Name = “Nancy”
Address = “Christchurch” Current location = “At home”
Name of class
Properties
Current location
Attend lecture
Properties
Name = “Elora”
Address = “Auckland” Current location = “In bed”
Example: UML class diagram (more next week)
BankAccount
owner: String balance: Dollars
deposit(amount:Dollars)
withdraw(amount:Dollars)
Class name
Properties
SavingsAccount
annualInterestRate: Percentage
depositMonthlyInterest()
withdraw(amount:Dollars)
Dependencies
CheckingAccount
insufficientFundsFee: Dollars
processCheck(checkToProcess: Check)
withdraw(amount:Dollars)
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
Remember from before
• Distinct types of activities, e.g.,
– Requirementsengineering
– Coding (“Java part” of course)
– Operation + maintenance
Testing (validation and verification)
• Validate: Are we building the right system?
– Customer feedback, reviews, acceptance testing, etc.
• Verify: Are we building the system right?
– Reviews, code testing (including problem analysis and reporting), etc.
• Typical challenges
– Howtoscaleup?
– How to detect problems early?
– How to perform validation and verification based on cost-benefit?
• More on testing later
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
Remember from last lecture…
• Distinct types of activities, e.g.,
– Requirementsengineering
– Coding (“Java part” of course)
– Operation + maintenance
Maintenance
• How to fix faults and make future changes (evolution)
• Software must change or it becomes less useful
– Adaptive
– Corrective (“debugging”)
– Preventive(including“refactoring”)
• Typical challenges
– How to avoid architecture / design erosion?
– How to accommodate (unknown) future changes?
– How to manage versions that exist simultaneously?
• More on maintenance later
1. UML in a nutshell
2. Requirements and use cases
4. Testing
5. Operation and maintenance
Cartoon of the day
Key lesson: Following good software engineering practices requires effort and involves different types of activities. Not following good practices leads to difficult to maintain software and unhappy users.
’s resolutions of software engineers, every year:
New year's resolutions (like for any other year) pic.twitter.com/qqTHmdP9Jw
— Mario Fusco 🇪🇺🇺🇦 (@mariofusco) December 22, 2020
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com