1. SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

2. Week 5 Larman’s OO Development Process Requirements –Use cases, domain models, system operation

3. Objectives “Think in Objects” Analyze requirements with use cases Create domain models Apply an iterative & agile Unified Process (UP) Relate analysis and design artifacts Read & write high- frequency UML Practice Apply agile modeling Design object solutions –Assign responsibilities to objects –Design collaborations –Design with patterns –Design with architectural layers –Understand OOP (e.g., Java) mapping issues

4. Basic Questions What is software design? How is it different from software programming? Software development? How do we design software? What is the role of objects, layers, architecture,..? What is the role of tests, responsibilities, patterns, models, …? How does design fit into the software lifecycle? What is good design? How does software design differ from … design?

5. Larman’s Design Process

6. Artifacts in the UP Use-Case Model

8. DEFINITION: Use Case Informally, a use case is a story of using a system to fulfill a goal. –Rent Videos Used by primary actors –E.g., Clerk –External agents –something with behavior Use supporting actors. –CreditAuthorizationSystem

9. DEFINITION: Scenario Informally, a scenario is a specific sequence of actions and interactions in a use case. –One path through the use case. –E.g., The scenario of renting videos and first having to pay overdue fines. More formally, a use case is a collection of success and failure scenarios describing a primary actor using a system to support a goal.

10. Use Case Diagrams Warning: Don’t spend much time on diagramming. Use case work means to write text, not draw diagrams

11. Guidelines: Use Case Diagrams

12. Types of Actors Primary actor – has goal, initiates task Supporting actor – involved in dialogue, provide services or information Off-stage actor – has an interest in the use case

13. Guidelines: Use Case Modeling It is common to group CRUD (Create, Read, Update, Delete) operations into one use case. –Manage Users Name starts with a verb. –Manage Users All systems have a Start Up and Shut Down use case (perhaps trivial and low level). –But sometimes, important. an avionics system

14. Detail in Use Cases Iterative writing of use cases: idea, basics, scenarios, fully dressed description “brief” format = terse one-paragraph summary “casual” format = one informal paragraph per scenario “fully dressed” format = everything you want

15. Use Cases: non-functional requirements Note that use cases can capture non-functional requirements Performance: indicate performance constraints on individual scenarios Security: indicate which tasks must be secure Usability: indicate user characteristics with actor definitions; indicate frequency of user events with use case, … Portability, etc: These are “developer” use cases, not “user” use cases

16. DEFINITION: Essential & Concrete Use Cases “Keep the UI out” Essential use cases defer the details of the UI, and focus on the intentions of the actors. Essential: Clerk enters Customer ID. Concrete/worse: Clerk takes Customer ID card and reads the bar code with laser scanner.

17. GUIDELINES: Types of Scenarios Main scenario Alternative scenario – other ways of achieving the goal Exceptional scenario – where something goes wrong Recovery scenario – but we can recover Failure scenario – alas, we cannot recover NB For Larman, “failure scenario” = “exceptional scenario”

18. MOTIVATION: Comprehensible & Familiar Use cases are stories. A simple and familiar model that many people, especially non-technical, can easily relate to.

19. DEFINITION & MOTIVATION: Domain Model A Domain Model visualizes, using UML class diagram notation, noteworthy concepts or objects. –It is a kind of “visual dictionary.” –Not a picture of software classes. It helps us identify, relate and visualize important information. It provides inspiration for later creation of software design classes, to reduce “representational gap.”

20. Domain Model

21. Domain Model and Domain Layer Low representational gap

22. Conceptual classes Fig. 9.5

23. Guidelines 9.5 reuse existing model; use category list (see Table 9.1) identify noun phrases 9.9 Include Report Objects, eg Receipt 9.10 Think like a mapmaker 9.11 How to model the ‘unreal’ world 9.13 Description class, eg ProductDescription

24. GUIDELINES: Associations Only add associations for noteworthy relationships. Literally, those for which making a “note” is worthy or business motivated.

25. Associations See Table 9.2

26. UML and GUIDELINES: Attributes Show only “simple” relatively primitive types as attributes. Connections to other concepts are to be represented as associations, not attributes.

27. SSDs, System Operations & Layers

28. Context – Organisational iterative requirements use cases sys. sequence diagrams domain models

29. Context – System Subsystem User-level use cases User work tasks User goals for task (External) actor-system dialogue Target system being modeled is the whole system But … can model use cases of a subsystem … Subsystem as target system Means other subsystems are actors external to the subsystem Means that a client of the service of the subsystem is an actor (client is another subsystem …) Still have tasks, goals, scenarios, etc Can construct a use case model iterative requirements use cases sys. sequence diagrams domain models

30. Context within artefacts

31. Context with SSDs

32. Ch 11: Operation Contracts Aim: Define system operations via contracts Operation Method Invariant Precondition Postcondition

33. Definitions Contract A contract specifies detailed changes, as a result of a system operation, to objects in the domain model using pre-conditions and post-conditions. Contract Format –Operation: name and parameters of operation. –Cross References: use cases that involve the operation. –Preconditions: noteworthy assumptions about the state of the system or object in the domain model before execution of the operation. –Postconditions: The state of objects in the domain model after completion of the operation. State A state is the condition of an object (or system) at a moment in time.

34. Describing the State of a System Describe the objects in the system Describe the links (relationships) between the objects Describe the properties of each object (ie the state of the object) = the (abstract) values of the object attributes [as in a state machine]

35. Invariant of a System or Object Invariant Is a condition which is always true about the state of the system (or object) Note: the state is only defined in between execution of operations Hence, invariant only has to be true before and after each operation, not during an operation

36. Postcondition Definition The postconditions describe changes in the state of objects in the domain model. Domain model state changes include instances created, associations formed or broken, and attributes changed. Note: postconditions are not actions to be performed during the operation They are the effect, ie observations about state of domain objects when the operation is finished. Ie, “what” not “how”

37. Writing Postconditions Document 1.Instance creation and deletion “A SalesLineItem sli was created” 2.Attribute change of value “sli.quantity became quantity” Note: quantity is an operation parameter 3.Association links formed and broken “sli was linked to the current Sale” “sli was linked with a productDescription based on itemID match” Use past tense.

38. Guidelines 1.Identify system operations from the SSDs. 2.For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract. 3.To describe the postconditions, document 1.Instance creation and deletion 2.Attribute modification 3.Links formed and broken Use past tense for postconditions. Remember to document the forming of links!