Upload
vikramsarangan
View
228
Download
0
Embed Size (px)
Citation preview
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
TodayFundamental UnderstandingInceptionUnderstanding RequirementsUse-Case Model: Writing Requirements in
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
TodayFundamental UnderstandingInceptionUnderstanding RequirementsUse-Case Model: Writing Requirements in
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