SOEN 6461-2_W2014

8/11/2019 SOEN 6461-2_W2014

1/51

1

SOEN 6461Software Design Methodologies:Lect_2

InceptionUnderstanding RequirementsUse-Case Model: Writing Requirements in Context

Chap: 4,5,6,7

8/11/2019 SOEN 6461-2_W2014

2/51

Iteration 1

Iteration 2

Iteration 3Introduces just thoseanalysis and designskills related toiteration one.

Additional analysis anddesign skills introduced.

Likewise.

SOEN6461: Learning path through iterations

Inception(req. Analysis )

OOA/D andresponsibilities'assignment toobjects

Object design,Design Patterns

Architecturalanalysis,frameworkdesign

2

8/11/2019 SOEN 6461-2_W2014

3/51

3

Today

Fundamental UnderstandingInceptionUnderstanding RequirementsUse-Case Model: Writing Requirements inContext

8/11/2019 SOEN 6461-2_W2014

4/51

8/11/2019 SOEN 6461-2_W2014

5/51

5

Some Obvious Parallels

Satisfaction of customers needs Specialization of laborMultiple perspectives of the final productIntermediate points where plans andprogress are reviewed

8/11/2019 SOEN 6461-2_W2014

6/51

6

Deeper Parallels

Architecture is different from, but linkedwith the product/structureProperties of structures are induced bythe design of the architectureThe architect has a distinctive role andcharacter

8/11/2019 SOEN 6461-2_W2014

7/51

7

Deeper Parallels (contd)

Process is not as important as architectureDesign and resulting qualities are at theforefront

Process is a means, not an endArchitecture has matured over time into adiscipline

Architectural styles as sets of constraintsStyles also as wide range of solutions,techniques and palettes of compatiblematerials, colors, and sizes

8/11/2019 SOEN 6461-2_W2014

8/51

8

More about the Architect

A distinctive role and character in a projectVery broad trainingAmasses and leverages extensive experienceA keen sense of aesthetics

Deep understanding of the domainProperties of structures, materials, andenvironmentsNeeds of customers

Even first-rate programming skills are insufficientfor the creation of complex software applications

But are they even necessary?

8/11/2019 SOEN 6461-2_W2014

9/51

9

Limitations of the Analogy

We know a lot about buildings, much less aboutsoftwareThe nature of software is different from that ofbuilding architecture

Software is much more malleable than physicalmaterialsThe two construction industries are very different Software deployment has no counterpart in building

architectureSoftware is a machine; a building is not

8/11/2019 SOEN 6461-2_W2014

10/51

10

But Still Very Real Power of Architecture

Giving preeminence to architecture offersthe potential forIntellectual controlConceptual integrityEffective basis for knowledge reuseRealizing experience, designs, and codeEffective project communication

Management of a set of variant systemsLimited-term focus on architecture willnot yield significant benefits!

8/11/2019 SOEN 6461-2_W2014

11/51

11

Fundamental Understanding

Architecture is a set of principal designdecisions about a software systemThree fundamental understandings ofsoftware architecture

Every application has an architectureEvery application has at least one architect

Architecture is not a phase of development

8/11/2019 SOEN 6461-2_W2014

12/51

12

Wrong View: Architecture as a Phase

Treating architecture as a phase denies itsfoundational role in software developmentMore than high -level design Architecture is also represented, e.g., byobject code, source code,

8/11/2019 SOEN 6461-2_W2014

13/51

13

Context of Software Architecture

RequirementsDesignImplementationAnalysis and TestingEvolution

Development Process

8/11/2019 SOEN 6461-2_W2014

14/51

14

Requirements AnalysisTraditional SE suggests requirements analysis shouldremain unsullied by any consideration for a designHowever, without reference to existing architecturesit becomes difficult to assess practicality, schedules,or costs

In building architecture we talk about specificrooms rather than the abstract concept means forproviding shelter

In engineering new products come from theobservation of existing solution and their limitations

8/11/2019 SOEN 6461-2_W2014

15/51

15

New Perspective on Requirements Analysis

Existing designs and architectures provide thesolution vocabularyOur understanding of what works now, and how itworks, affects our wants and perceived needsThe insights from our experiences with existingsystems

helps us imagine what might work and

enables us to assess development time and costs Requirements analysis and consideration of designmust be pursued at the same time

8/11/2019 SOEN 6461-2_W2014

16/51

16

Non-Functional Properties (NFP)

NFPs are the result of architectural choicesNFP questions are raised as the result ofarchitectural choicesSpecification of NFP might require anarchitectural framework to even enable theirstatement

An architectural framework will be requiredfor assessment of whether the properties areachievable

8/11/2019 SOEN 6461-2_W2014

17/51

17

The Twin Peaks Model

8/11/2019 SOEN 6461-2_W2014

18/51

8/11/2019 SOEN 6461-2_W2014

19/51

19

Architecture-Centric Design

Traditional design phase suggests translating therequirements into algorithms, so a programmer canimplement themArchitecture-centric design

stakeholder issuesdecision about use of COTS componentoverarching style and structurepackage and primary class structuredeployment issuespost implementation/deployment issues

COTS:Commercial off-the-shelf

8/11/2019 SOEN 6461-2_W2014

20/51

20

Design Techniques

Basic conceptual toolsSeparation of concernsAbstractionModularity

A widely adapted strategyObject-oriented design

8/11/2019 SOEN 6461-2_W2014

21/51

21

Object-Oriented Design (OOD)

ObjectsMain abstraction entity in OODEncapsulations of state with functions foraccessing and manipulating that state

8/11/2019 SOEN 6461-2_W2014

22/51

22

Pros and Cons of OOD

ProsUML modeling notationDesign patterns

Cons

Provides onlyOne level of encapsulation (the object)One notion of interfaceOne type of explicit connector (procedure call)

Even message passing is realized via procedure callsOO programming language might dictate importantdesign decisions

8/11/2019 SOEN 6461-2_W2014

23/51

23

TodayFundamental UnderstandingInceptionUnderstanding RequirementsUse-Case Model: Writing Requirements in

Context

8/11/2019 SOEN 6461-2_W2014

24/51

The NextGent POS System (1/2)

A POS system computerized application used to recordsales and handle payments typically used in retail stores.POS includes:

Hardware components(computer and bar code scannerSoftware

POS interfaces to various service application (e.i. Taxcalculator and inventory control)POS system supports multiple client-side terminals andinterfacesPOS a commercial system for different clients withdisparate needs in terms of business rule processing:flexibility and customization

24

8/11/2019 SOEN 6461-2_W2014

25/51

25

Case Study Focus

Many systems can be divided into 3 layers

User interfaceBusiness logic (application)

Integration (DB & other systems)

Focus is on business layer becauseIts design is less technology dependent OOAD skills can be applied to other layersMore likely to have stable design

8/11/2019 SOEN 6461-2_W2014

26/51

The NextGen POS System (2/2)

User Interface

Sale Payment

Logging ... Database Access ...

applicationlogic layer

other layers orcomponents

minor focus

explore how to connect toother layers

primary focusof case studies

explore how todesign objects

secondaryfocus

26

8/11/2019 SOEN 6461-2_W2014

27/51

8/11/2019 SOEN 6461-2_W2014

28/51

8/11/2019 SOEN 6461-2_W2014

29/51

29

What artifacts may start ininception? (2/2)

Prototypes and proof-of-conceptsIteration plan

Describes what to do in the first elaboration iterationPhase Plan & Software development Plan

Guess for elaboration phase duration. Tools, people,education and other resources.

Development CaseDescription of the customized UP steps and artifactsfor this project.

Artifacts will be partially completed in this phaseand will be refined in later iterations.

8/11/2019 SOEN 6461-2_W2014

30/51

30


Context

8/11/2019 SOEN 6461-2_W2014

31/51

31

Introduction to Requirements

Requirements are system capabilities and conditions to whichthe system must conform.Functional requirements

Features and capabilities.Recorded in the Use Case model (see next), and in thesystems features list of the Vision artifact.

Non-functional (or quality requirements)Usability (Help, documentation, ), Reliability (Frequency offailure, recoverability, ), Performance (Response times,availability, ), Supportability (Adaptability, maintainability,) Recorded in the Use Case model or in the SupplementarySpecifications artifact.

The nature of UP supports changing requirements.

8/11/2019 SOEN 6461-2_W2014

32/51

Types and Categories of RequirementsFunctional: Features, capabilities, securityUsability: human factors, help documentationReliability: frequency of failure, recoverabilityPerformance: response time, accurarcy

Suportability: adaptability, maintainabilityImplementation: language, tools, hardwareInterface: interfacing with extern systemsOperations: system management in its oper. setting.Packaging: example physical boxLegal: licensing

SWEBOK: Software Engineering Body of KnowledgeWriting Effective Use Cases, by Cockburn, A. 2001 32

8/11/2019 SOEN 6461-2_W2014

33/51

33


Context

8/11/2019 SOEN 6461-2_W2014

34/51

Use-Case Model

Operation:enterItem( )

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1.. *1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes,associations

R e q u i r e - m e n t s

B u s i n e s sM o d e l i n g

D e s i g n

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

systemevents

Cashier

ProcessSale

: Cashier

usecase

names

systemoperations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals,actors, features

terms, attributes,validation

non-functional reqs,quality attributes

requirements

Process Sale

1. Customerarrives ...2. Cashiermakes newsale.3. ...

34

8/11/2019 SOEN 6461-2_W2014

35/51

35

Use cases and adding value

Actor: something with behavior, such as aperson, computer system, or organization,e.g. a cashier.

Scenario: specific sequence of actions andinteractions between actors and thesystem under discussion, e.g. the scenarioof successfully purchasing items with cash.Use case: a collection of related successand failure scenarios that describe actorsusing a system to support a goal.

8/11/2019 SOEN 6461-2_W2014

36/51

The kind of actors

ActorsPrimary actor : has user goals: e.g.: cashier)Supporting actor : provides a service:e.g.automated payment serviseOffsatge actor: has an interest in thebehavior of the use case but not primary or

supporting a government tax agency

36

8/11/2019 SOEN 6461-2_W2014

37/51

37

Use cases and adding valueHandle returnsMain success scenario : A customer arrives at a

checkout with items to return. The cashier usesthe POS system to record each returned item

Alternate scenarios :If the credit authorization is reject, inform

customer and ask for an alternative paymentmethod.

If item identifier not found in the system, notifythe Cashier and suggest manual entry of theidentifier code.

8/11/2019 SOEN 6461-2_W2014

38/51

38

Use cases and adding value

A key point is to focus on the questionhow can using the system provideobservable value to the user, or fulfilltheir goals? Use cases mainly constitute functionalrequirements.

8/11/2019 SOEN 6461-2_W2014

39/51

39

Use case types and formats

Black-box use cases describe systemresponsibilities, i.e. define what the system mustdo.

Uses cases may be written in three formalitytypesBrief: one-paragraph summary, usually of the mainsuccess scenario.Casual: Informal paragraph format (e.g. Handle returns)Fully dressed: elaborate. All steps and variations arewritten in detail.

8/11/2019 SOEN 6461-2_W2014

40/51

40

Fully-dressed example:Process SaleUse case UC1: Process SalePrimary Actor: CashierStakeholders and Interests:

-Cashier: Wants accurate and fast entry, no payment errors, -Salesperson: Wants sales commissions updated.

Preconditions: Cashier is identified and authenticated.Success Guarantee (Postconditions):

-Sale is saved. Tax correctly calculated.

Main success scenario (or basic flow): [see next slide]

Extensions (or alternative flows): [see next slide]Special requirements : Touch screen UI, Technology and Data Variations List:

-Identifier entered by bar code scanner, Open issues : What are the tax law variations?

8/11/2019 SOEN 6461-2_W2014

41/51

41

Main success scenario (or basic flow):The Customer arrives at a POS checkout with items to purchase.The cashier records the identifier for each item. If there is more thanone of the same item, the Cashier can enter the quantity as well.The system determines the item price and adds the item information tothe running sales transaction. The description and the price of the currentitem are presented.On completion of item entry, the Cashier indicates to the POS systemthat item entry is complete.The System calculates and presents the sale total.The Cashier tells the customer the total.The Customer gives a cash payment (cash tendered) possibly greater than the sale total.

Extensions (or alternative flows):If invalid identifier entered. Indicate error.If customer didnt have enough cash, cancel sales transaction.

Fully dressed example:Process Sale (cont.)

8/11/2019 SOEN 6461-2_W2014

42/51

8/11/2019 SOEN 6461-2_W2014

43/51

43

Finding primary actors, goals anduse cases

Choose the system boundary.Identify primary actors.

Those that have user goals fulfilled through

using services of the systemFor each actor identify their user goals.Tabulate findings in the Vision artifact.

Define use cases that satisfy user goals;name them according to their goal.

8/11/2019 SOEN 6461-2_W2014

44/51

44

Essential vs. Concrete style

Essential : Focus is on intend.Avoid making UI decisionsConcrete : UI decisions are embedded inthe use case text.

e.g. Admin enters ID and password in thedialog box (see picture X) Concrete style not suitable during early

requirements analysis work.

8/11/2019 SOEN 6461-2_W2014

45/51

45

Use Case Diagrams

NextGen

Cashier Handle returns Payment Authorization

ServiceProcess Rental

Tax Calculator

Primary actors tothe left: have user goals.

Supporting actors tothe right: they providea service.

Alternative notation forcomputer system actor

Process Sale

8/11/2019 SOEN 6461-2_W2014

46/51

Primary actors and goals at differentsystem boundaries

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collecttaxes on sales Sales ActivitySystem

Goal: Analyze salesand performance data

46

8/11/2019 SOEN 6461-2_W2014

47/51

Partial use case context diagramNextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

actorTax Calculator

actorAccounting

System

alternatenotation fora computersystem actor

actorHR System

Cash In

actorSales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

47

8/11/2019 SOEN 6461-2_W2014

48/51

Notation suggestions

NextGen

Process Sale

. . .

Cashier

Show computer system actorswith an alternate notation to

human actors.

primary actors onthe left

supporting actorson the right

For a use case contextdiagram, limit the use cases to

user-goal level use cases.

actorPayment

AuthorizationService

48

8/11/2019 SOEN 6461-2_W2014

49/51

8/11/2019 SOEN 6461-2_W2014

50/51

Supplementary Specification: captures other kind ofrequirements: reports, documentation, licensingGlossary: captures terms and definitions, datadictionary

Business Rules: captures rules and policies

Other requirement artifacts (chap. 7, p 102)

50

8/11/2019 SOEN 6461-2_W2014

51/51

Documents

SOEN 6461-2_W2014