Software Engineering Lecture 2

1. Software Engineering Lecture 2

2. Thoughts?

3. Assignments (Weekly Deliverables!) W36 A0. Registration W37 A1. Project Portfolio Skeleton (5p) W38 A2. Requirement Specification (17p) W39 A3. Design Patterns (6p) W40 A4. System Design (17p) W41 A5. Code review Report (5p) W42 A6. Complete Project Portfolio (10p) W43 A7. Project Presentation & Demo (10p) W44 A8. ”Home Exam” (21p) Quizzes (9p) Workflow (Deliverables) - 5 p if late! - All p if bad! Deadlines are 17.00 every Friday!!!

4. Deadline A0 – Registration, 7/9 17.00 • Start up your teams immediately! • Attach roles (1 per team member) • PrjMgr, ReqEng, SysArch, (Q, TestEng) • Study the problem to solve! Start reading the book! • E-mail the team info [A0] to josef.hallberg@ltu.se • Team/Project name • Contact details (name, email, phone) • Roles in the project • Background of members (1/2 A4 CV of each member) • Goals for the team • Set up weekly meetings • Prepare for weekly deliveries! • The project manager should not do all work himself! • Share work, work in pairs, act like a team! • Report and keep track of time! 5 manweeks go fast... • Be prepared for hard work!  • Invite ”the Expert” for an interview in 1-2 weeks! (See Doodle) Deadline 0

5. Project Description [A1] 1.1 Problem Definition (Use your own words based on the scenario) [A1] 1.2 Project Management (Members, Roles, Meetings, Deliveries, Task Planning) [A1/A6] 1.3 Resource and Activity Plan [A6] 2. Requirements Specification [A2] 2.1 User Characteristics - Actors [A2] 2.2 Use Cases and Functional Requirements (including Use Case Diagrams) [A2]2.3 System and Non-functional Requirements [A2]2.4 User Requirements [A2]2.5 Interface Specification and Storyboards [A2]2.6 Testability [A2] 3. System Design [A5] 3.1 Static (Compile-time) Design [A5]3.1.1 Class Diagrams [A5]3.1.2 Module Diagrams [A5]3.2 Dynamic (Run-time) Design [A5]3.2.1 Activity Diagrams [A5]3.2.2 Sequence Diagrams [A5]3.2.3 State Diagrams [A5] 4. Demonstrator (Description and Screenshots) [A8] 4 Iterations of the Project Portfolio [A 1,2,5,6] One Code Review Exercise [A 3] One Design Patterns Exercise [A4] Home exam on the book [A7] One Presentation and Demo [A 8] Tutor Meetings Weekly Group Meetings Plan Ahead!!! Deadline A1 - Project Portfolio, 14/9 17.00 Deadline

6. Recap • Goals [ and what is required ] • On time [predictable process/milestones ] • Within budget [ predictable process/cost analysis ] • Meet changing, competing and contradictory requirements [ risk/requirement analysis ] • Well enough [ quality assurance ] • How [ and with what ] • Design code as atomic entities [ OO ] • Use models to break down complexity [ UML ] • Reuse schemas [ Design Patterns ]

7. Today • The beginning of the development process... • The Uniform Modeling Language (UML) • The System Expert and The User Group • Actors • Use Cases • Use Case Diagrams • Activity Diagrams • Storyboards • Roles and Responsiblities

8. Modeling using UML • DeFacto standard for modeling object-oriented systems. • Resulted from the convergence of notations from three leading object-oriented methods: • OMT (James Rumbaugh), development processes • OOSE (Ivar Jacobson), objectory or use-case driven design • Booch (Grady Booch), notation

9. A model gives the illusion of simplicity! KISS – Keep It Simple, Stupid!

10. Modeling using UML Modeling is a central part of all the activities that lead up to the deployment of good software. We use models to: • Understand the system as a whole and in parts • Visualize and control the system’s architecture • Communicate desired system structures and behavior • To identify cases of abstraction and reuse • Manage risks You can model 80% of most problems by using ~20% UML!

11. Modeling complex systems We need to describe the architecture and behaviour of complex systems!

12. Models abstracts the complexity of systems so they become understandable. The models are often expressed as: Text Diagrams Structured Data The four basic principles of modeling: The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Every model may be expressed at different levels of precision. The best models are connected to reality (models an abstracted reality). No single model is sufficient, as every nontrivial system is best approached through a small set of nearly independent models. Modeling using UML

13. Modeling using UML Diagrams are the main artefacts when using UML. (These are not a sequence of steps!!!!) • Use case diagrams • Functional behavior of the system as seen by the user. • Activity diagrams • Dynamic behavior of a system expressed as a flowchart. • Sequence diagrams • Dynamic behavior between actors and system objects. • State-chart diagrams • Dynamic behavior of an individual object. • Class diagrams • Static structure of the system: Objects, Attributes, and Associations. • etc...

14. Artifacts Actors Use Cases Use Case Diagrams StoryboardsRequirements Specification Black BoxRequirements FunctionalSpecification Diagrams: - Class- Sequence- Statechart- Activity Design Patterns System Design SystemTest SystemDesign Test PlanTest Cases SystemDevelopment SystemValidation Notes and Details Signatures Design Patterns

15. An evolutionary development process User Group Black BoxRequirements FunctionalSpecification SystemTest SystemDesign SystemExperts User Group SystemDevelopment SystemValidation On time, within budget and meet requirements!

16. System Experts • You cannot do a good design if the main requirements are unknown! Feedback from the users are vital. • A system expert can give you invaluable help in the design of your system, especially when it comes to interaction and usage. • The system expert can be, and is likely to be, a user. • Use the system expert especially to identify the use cases of the system.

17. An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides thesystem with GPS coordinates Passenger Actors

18. A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements PurchaseTicket Use Case

19. A use case is basically a functional view of the system The print method Finding a webpage The most commonly used use cases are the most important to get right! Do not try to capture all the details right at the start – allow for iteration and discussion! Use cases should also affect how the system is tested during development! Use Cases

20. Package Actor Use case Use Case Diagrams SimpleWatch ReadTime SetTime WatchUser WatchRepairPerson ChangeBattery Use case diagrams represent the functionality of the system from user’s point of view.

21. Name:Change Battery Participating actors:WatchRepairPerson Entry condition: WatchRepairPersonhas a new battery. Exit condition: WatchRepairPersonhas changed to a new battery. Event flow: 1.WatchRepairPerson opens the clock and replaces the old battery with a new battery. Use Case Example 1

22. Name:Purchase ticket Participating actor:Passenger Entry condition: Passengerstanding in front of ticket distributor. Passengerhas sufficient money to purchase ticket. Exit condition: Passengerhas ticket. Event flow: 1.Passengerselects the number of zones to be traveled. 2. Distributor displays the amount due. 3.Passengerinserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Use Case Example 2

23. <<extend>> relationships represent exceptional or seldom invoked cases. The exceptional event flows are factored out of the main event flow for clarity. Use cases representing exceptional flows can extend more than one use case. The direction of a <<extend>> relationship is to the extended use case Passenger PurchaseTicket OutOfOrder TimeOut Cancel NoChange The <<extend>> Relationship <<extend>> <<extend>> <<extend>> <<extend>>

24. <<include>> represents behavior that is factored out of the use case for reuse (not because it is an exception) Direction of <<include>> is to the using use case (unlike <<extend>> relationships). Passenger PurchaseMultiCard PurchaseSingleTicket CollectMoney NoChange Cancel The <<include>> Relationship <<include>> <<include>> <<extend>> <<extend>>

25. DMS 2005 Example 1

26. DMS 2005 Example 2

27. 5 Minutes of Oxygen

28. Activity Diagrams • An activity diagram shows flow control within a system • An activity diagram is a special case of a state chart diagram in which states are activities (“aggregated functions”) • These are related to use cases!

29. Activity Diagram: Modeling Decisions

30. Splitting Synchronization Allocate Resources Open Coordinate Archive Incident Resources Incident Document Incident Activity Diagrams: Modeling Concurrency • Synchronization of multiple activities • Splitting the flow of control into multiple threads

31. Dispatcher Allocate Resources Open Coordinate Archive Incident Resources Incident FieldOfficer Document Incident Activity Diagrams: Swimlanes • Actions may be grouped into “swimlanes” to denote the object or subsystem that implements the actions.

32. Storyboarding • Storyboarding is an excellent technique to visualize interaction! • Make atleast one per major use case • ”A step by step visualization of the users actions” • The primary tools: pen and paper!( CASE-tools…=…Carbon Assisted Software Engineering  )

33. Storyboard example Actor: CustomerUse Case: Rent Movie Enter shop. Locate terminal. Use terminal.

34. Storyboard example Select criteria. Select criteria. Enter title. Enter title. Verify selection. Print selection.

35. Storyboard example Locate counter. Verify selection. Show selection. Wait for film.

36. Storyboard example Verify film. Pay and show ID. Exit shop. Get film and ID.

37. Graphichal storyboards, example 1 1. Select Movies 2. Select personal movie (King Kong) 3. Select to search 4. Enter characters (filtering) 5. Select found movie (Rambo FB) 6. Select to Play movie (Rambo FB)

38. Storyboards • Write which actor and use case is described by the storyboard! • Name and number each picture so that you can refer to them easily! • Always start with the entry condition, where the user starts interacting with the system (Just like with the use case). • Always end with the exit condition, where the user stops interacting with the system (Just like with the use case). • Only do one step at a time! It should be easy to understand! • Show the activity! What happens? Describe what happens between each picture.

39. Storyboards, but what next? • Use the storyboards to get feedback on your use cases from the user group and the system expert (me). • The less unknown, the less risks! • The storyboards are your first prototypes! • Paper is cheap and quick to use! • Feedback from users almost immediately! • Show picture after picture and ask the user to complete a task, study, and learn! Find faults early! • Note that everything is linked together: • Use case • Storyboard • Activity diagram • Sequence diagram • Test case Faults in how a system should be usedleads to very expensive corrections – If they are even possible to correct!

40. Develop the text description of your system. Identify the actors of the system. Try to find the actors uses of the system and express them as use cases. Attach values to the use cases: Cost (Time/Resources) Value (Customer) Risk (Unknown/Complexity) Dependencies on other use cases Priority Metrics (How to measure) Start with a minimal set of use cases – then evolve!!! Make use case diagrams to view how use cases relates to actors. Draw activity diagrams where activities (use cases) are related! Make simple storyboards on paper for the use cases – it will make these simpler to understand. Make paper prototypes! (rapid prototyping) Make prototypes! Throw away! Start small! Evolve! How to do a design...IMHO!

41. =2*2*6=24 1 =4*7*2=56 3 =5*2*7=70 4 =3*5*5=75 5 =4*4*7=112 6 =1*5*4=20 2 Example table of Use Cases Developmentorder CVR

42. ”Failing gracefully” • Experience is won through an equal amount of successes and failures. • One way to become truly successful is to know how to ”fail gracefully”! • Start small and simple, then evolve in small steps! • A failure does not mean that too much is lost. It’s small! • Manage risks by: • Identifying risks early, then weigh value against risk to prioritize work. • Doing the parts of the system with least value/risks ratio last! • Starting with studying critical risks! (The hardest parts)

43. Develop the description of your system further. Identify the actors of the system Try to find the actors uses of the system and express them as use cases. Attach initial values to the use cases: Cost (Time/Resources) Value (Customer) Risk (Unknown/Complexity) Dependencies on other use cases Priority Metrics Start with a minimal set of use cases – then evolve!!! Make simple storyboards on paper for unclear use cases – it will make these simpler to understand Make use case diagrams to view how use cases relates to actors Draw activity diagrams where activities (use cases) are related! Deadline – A2 Requirements (part one) Deadline

44. First advisory meeting I want to meet your groups independently! • To see that you are starting up ok • To answer questions that may not come up in class • To give advice on group work and setup • To give feedback and adjust your project ideas • To be the ”User Expert” for assignment 2 • Invite me (see Doodle for available time-slots) • Then another meeting, later!

45. Teams ProjectManager RequirementsEngineer SystemArchitect QualityEngineer Test Engineer

46. Roles and Responsibilities • Project Manager • Project Description, Project Portfolio • Requirements Engineer • Requirements Specification • System Architect • Software Design Document • Quality Engineer • Inspection Leader, Code Review Report • Test Engineer • (Test Cases and Test Plan,) Traceability Help Each Other!

47. Next lecture Model-based Design(focus on models of system functionality and architecture)- motivation for MBD- functional and structural (architectural) models- model as a means of abstraction- relation between a model and a system- multiple models, relation between different models of the same system- examples of models, UML as a modeling language- examples of tools for modeling- role of modeling in the software production process, simulation of models- executable models, automatic code generation

48. The End That’s all folks! Thanks for your attention! Questions??