Lecture 1 SOFTWARE DEVELOPMENT PB007 Software Engineering I Faculty of Informatics, Masaryk University Fall 2018 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: Barbora Bühnová ² Industrial experience § Association of Industrial Partners (SPP) ² Research § Lab of Software Architecture and Information Systems (LaSArIS), FI MU § CERIT Scientific Cloud, ICS MU ² Teaching § Courses on UML, software quality, architecture design, programming, algorithm design, and others ² Collaboration with students § Bachelor/Master theses (Honeywell, Kiwi.com, IBM) § 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. Data modelling, Entity Relationship diagram. 8. Design-level Class diagram, interfaces, implementation details. 9. State diagram. 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 backup week ² Seminars § 12 teaching weeks + 1 final-consultation (or backup) week § Team project on UML modeling, teams of 3 students § 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 lives 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, traffic monitoring systems. ² Online services § Multi-device applications and online services. § Examples – Google services, social networks. Chapter 1 Introduction 12 Application types ² Stand-alone desktop applications ² Interactive web-based applications ² Embedded control systems ² Batch processing systems ² Computer games ² Mobile apps ² Data collection and monitoring systems ² IoT systems Chapter 1 Introduction 13 Software engineering fundamentals ² Some fundamental principles apply to all types of software system, irrespective of the type ² The SW 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 14 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. 15Chapter 2 Software Processes Software process models Chapter 2 Software Processes 16 Agile Early SCRUM Agile Manifesto Spiral UML in Software Development Lecture 1/Part 3 17Chapter 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 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 18 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 19 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 20 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 21 UML Use Case Diagram Lecture 1/Part 4 22Chapter 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» 23Chapter 4 Requirements engineering © Clear View Training 2010 v2.6 24 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 § But focusing on functional requirements only MedicalSystem Functional and non-functional requirements ² Functional requirements § Statements of services the system provides, how the system should react to particular inputs and how the system should behave in particular situations. § E.g. A user shall be able to search the appointments lists for all clinics. ² Non-functional requirements § Properties and constraints on the services offered by the system such as timing, reliability and security constraints, constraints on the development process, platform, standards, etc. § E.g. The system shall be available on Mon–Fri, 8 am – 5 pm, with downtime not exceeding five seconds in any one day. 25Chapter 4 Requirements engineering © Clear View Training 2010 v2.6 26 Use Case modelling process ² 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 MedicalSystem © Clear View Training 2010 v2.6 27 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 28 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 29 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 30 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 31 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 32 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 33 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 34 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 35 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 36 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 ² 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) The © Clear View Training 2010 v2.6 37 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 38 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 39 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 3.1. The system plays some background music. 3.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 40 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 41 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 42 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 43 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 44 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 45 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 46 «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 47 «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 48 «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 49 <> 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 50 Requirements tracing There is a many-to-many relationship between requirements and use cases: § One use case may cover 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 51 Key points ² Use cases describe system behaviour from the point of view of actors. They have highest value 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!