SOEN 6011 Software Engineering Processes

1
SOEN 6011Software Engineering Processes

• Section SS Fall 2007
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/soen6011-f2
  007.html

2
Week 5

• Larmans 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
Larmans Design Process
6
Artifacts in the UP Use-Case Model
7
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 Dont spend much time on
diagramming. Use case work means to write text,
not draw diagrams
11
Guidelines Use Case Diagrams
12
Guidelines Use Case Diagrams

• 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
• Instance creation and deletion
• A SalesLineItem sli was created
• Attribute change of value
• sli.quantity became quantity
• Note quantity is an operation parameter
• 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

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