UML 2 Activity Diagrams 11 - UML & Requirementsadrion/520-f03/PDF-links/11-UML-Reqmt.pdf11 - UML & Requirements ... Activity Diagram Notation ßInitial node ßfilled circle = starting

CMPSCI520/620

”Rick Adrion 2003 (except where noted) 1

UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003

11 - UML & Requirements

Rick Adrion


Scott W. Ambler , Copyright 2003 www.agilemodeling.com/

UML 2 Activity Diagrams

ßobject-oriented equivalent of flow charts and data flowdiagrams (DFDs) from structured development

ßtypically used forßbusiness process modeling

ßmodeling the logic captured by a single use case orusage scenario

ßmodeling the detailed logic of a business rule

ßcould potentially modelßthe internal logic of a complex operation

ßfar better to simply rewrite the operation so that it issimple enough that you don’t require an activity diagram



Activity Diagram Notationß Initial nodeß filled circle = starting point of the

diagram, not requiredß Activity final nodeß filled circle with a border is the

ending point, can have zero ormore activity final nodes.

ß Activityß rounded rectangles represent

activities, may be physical orelectronic

ß Flow/edgeß arrows on the diagram

ß Forkß A black bar with one flow going

into it and several leaving it,parallel activity.

ß Joinß A black bar with several flows

entering it and one leaving it,denotes the end of parallelprocessing.

ßConditionß a guard which must evaluate to

true in order to traverse the node

ß Decisionß A diamond with one flow entering and

several leavingß Mergeß A diamond with several flows entering

and one leaving, all incoming flowsmust reach this point until processingcontinues, unless otherwise noted

ß Partitionß also called swimlanes, indicating

who/what is performing the activitiesß Sub-activity indicatorß rake in the bottom corner of an activity

indicates that the activity is describedby a more finely detailed activitydiagram.

ß Flow finalß circle with the X through it, process

stops at this point.ß Use caseß non-official? indication that an included

use case is being invoked.


University enrollment example


Fill outforms

Apply toUniversity

Imputforms Input

applicantinfo

Displaycreate student

screen

Checkapplicant

list

Searchfor

applicantDisplaylist of

matches

Selectapplicantfrom list

Createstudent

Enrollin

seminar[incorrect]

[correct]

[not on list]

[on list]

[no match]

[potential matches]

[not on match list] [on match list]

Must be onlist of applicants,but not in system

y

y

xapplicant

registrar

system

“Swim lanes”

CMPSCI520/620





Fill outforms

Apply toUniversity

Imputforms

Inputapplicant

info

Displaycreate

studentscreen

Verifyapplicantis on list

See ifapplicant

Is in system

Displaylist of

matches

Createstudent

[incorrect]

Basic Course

[not on list]

[on list]

[no match]

[potential matches]

[not on match list]

[on match list]

B: Forms not filled out G: Not eligible to enroll

Exisiting Use Case F: Student may be in System

H

PerformSecurityCheck

PossibleSecurity

Risk

Use-casecourse of action

AlternativeUse-casetriggered




signal

time

pin

object


When to Use Activity Diagrams

ßUse activity diagrams when the behavior you aremodeling ...ßdoes not depend much on external events.ßmostly has steps that run to completion, rather thanbeing interrupted by events.ßrequires object/data flow between steps.ßis being constructed at a stage when you are moreconcerned with which activities happen, rather thanwhich objects are responsible for them (except partitionspossibly).


Activity Diagram Modeling Tips

ßControl flow and object flow are not separate. Both aremodeled with state transitions.

ßDashed object flow lines are also control flow.

ßYou can mix state machine and control/object flowconstructs on the same diagram (though you probablydo not want to).

CMPSCI520/620



Wrap Up: Activity Diagrams

ßUse Activity Diagrams for applications that are primarilycontrol and data-driven, like business modeling …

… rather than event-driven applications like embeddedsystems.

ßActivity diagrams are a kind of state machine until UML2.0 …

… so control and object/data flow do not have separatesemantics.


Statechart modeling

ßCaptures dynamic changes of class states – the lifehistory of the classßThese dynamic changes describe typically the behaviorof an object across several use casesßState of an object – designated by the current values ofthe object's attributesßStatechart Diagram – a bipartite graph ofßstates (rounded rectangles) andßtransitions (arrows) caused by eventsßThe concepts of states and events are the sameconcepts that we know from Activity Diagrams – thedifference is that “the states of the activity graphrepresent the states of executing the computation, notthe states of an ordinary object”


Types of Events

ßUML defines 4 kinds of eventsßSignal EventßAsynchronous signal received

ße.g. evFlameOn

ßCall Eventßoperation call received

ße.g. op(a,b,c)

ßChange Eventßchange in value occurred

ßTime EventßRelative time elapse

ßAbsolute time arrived

ße.g. tm(PulseWidthTime)


Types of Events

ßEvents are occurrences of interest that have bothßLocation

ßAbsolute time of occurrence

ßSignal events associate with SignalsßA Signal is a specification of an asynchronouscommunication between structural elements (e.g.objects)

ßOne type of Signal is Exception

CMPSCI520/620



States and transitions

ßObjects change values of their attributes but not all suchchanges cause state transitions

ßWe construct state models for classes that haveinteresting state changes, not any state changes

ßStatechart Diagram is a model of business rulesßBusiness rules are invariable over some periods of time

ßThey are relatively independent of particular use cases


Statecharts & Activity Diagrams

Heinrich Hussmann


States and transitions

Heinrich Hussmann


Statechart Diagram

ß Normally attached to a class, but can be attached toother modeling concepts, e.g. a use case

ß When attached to a class, the diagram determineshow objects of that class react to eventsß Determines – for each object state – what action the

object will perform when it receives an eventß The same object may perform a different action for

the same event depending on the object’s stateß The action’s execution will typically cause a state

change

CMPSCI520/620



Statecharts

ßCapture state-dependent requirements

ßStatechart created for each state-dependent class

ßUML provides hierarchical state transition diagramsßBased on Harel statecharts

ßInformation CapturedßStatesßCapture all possible states of the class

ßEvents and conditions

ßDescribe transitions between statesßActions

ßIndicate processing that occurs on entry or exit to/from astate


Statechart notation


Example


Nested submachines

CMPSCI520/620



Implementation diagrams

Deployment Diagram

Heinrich Hussmann

Component Diagram


Requirements Process & Products

Market AnalysisSystems AnalysisBusiness Planning

Systems Engineering

Market NeedsBusiness Needs

System Requirements

Requirements AnalysisRequirements Definition

System Specification

Requirements DefinitionRequirements Document

Requirements Specification

Specification

Behavioral SpecificationSystem Specification

Functional SpecificationSpecification Document

Requirements Specification


System Planning

ßBusiness strategyßSmall organizations

ßLarge organizations

ßApproachesßStrength, Weaknesses, Opportunities, Threats (SWOT)

ßValue Chain Model (VCM)

ßBusiness Process Re-Engineering (BPR)

ßInformation Systems Architecture (ISA)

ßEffectiveness vs. efficiency


Approaches

ßSWOTßTop-down classification, ranking and selection of projectsbased on: mission statement, internal strengths andweaknesses, external opportunities and threats, objectives,goals, strategies, and policies

ßVCMßLook at “value chain” – from raw materials to final productssold and shipped to customers and identify critical areaswhere IT can transform organization’s value chain

ßBPRßAimed at radical redesign of business processes, based onbusiness process”ownership,” and horizontally cross-cuttingprocesses with end at points of contact with customers. ITsupport enables BPR

ß ISAßA neutral architectural framework with stakeholders (planner,owner, designer, builder, subcontractor) and activities(what,how, where, who, when, why)

CMPSCI520/620



Systems and management levels


SW Requirements Defn Process

ßRequirements identification

ßIdentification of software development constraints

ßRequirements analysis

ßRequirements representation

ßRequirements communication

ßPreparation for validation of software requirements

ßManaging the requirements definition process definitionprocess.


Source of requirements


Requirements identification

ßelicited from people or derived from systemrequirements

ßSoftware needs -- Context analysisßdocuments why software is to be created and whycertain technical, operational, and economic feasibilitiesestablish boundary conditions

ßElicitation from people

ßDeriving from system planning requirements

ßTask analysis to develop user interface

CMPSCI520/620



More steps

ßIdentification of software development constraintsßCosts, hardware/software, reliability, portability

ßRequirements analysisßAssessment of potential problems

ßClassification of requirements mandatory, desirable, andnon-essential

ßEvaluation of feasibility and risks


Requirements representation

ßUse of modelsßA good model:ßReduces the amount of complexity that must becomprehended at one time.

ßIs inexpensive to build and modify compared to the realthing.

ßFacilitates the description of complex aspects of the realthing.

ßRoles for prototypingßprototype is not a substitute for a thorough writtenspecification

ßa system can be captured in a prototype


More steps

ßRequirements communicationßPresent to stakeholders for review

ßPreparation for validation of software requirementsßEstablish criteria

ßIdentify techniques to be used

ßManaging the requirements definition process definitionprocess.ßa major project management challenge.

ßan application that must support five different classes ofusers with significantly different expectations couldeasily involve a requirements definition process that isfive times more difficult than the corresponding processfor a homogeneous group


Software Requirement Products

ßRequirements definitionßFunctional

ßNon-functional

ßInverse

ßDesign & implementation constraints

ßRequirement documentsßStandards

ß“C-requirements”

ß“D-requirements”

CMPSCI520/620



Customer/Developer

ßObjectivesßRanking of attributesßKey contentsß“C-requirements”ßFunctionalityß Information definitionsßCritical non-functional requirementsßCritical design constraintsßAcceptance criteria

ß“D-requirements”ßFunctionalityß Information definitionsß Interfaces to external systemsßCritical non-functional requirementsßCritical design constraintsßAcceptance criteria and tests


Outcomes of a Good Process

ßThe buyers or usersßoften begin with only a vague idea of what they really needand with little idea of what software technology might offer.

ßa good process helps them explore and fully understand theirrequirementsßseparation of what they want and what they need

ßconstraints that might be imposed on the system by technology,organizational practices or government regulations.

ßunderstand alternatives, both technological and procedural, thatmight be considered in the proposed system

ßunderstand the tradeoffs

ßa good understanding of the implications of their decisions fiß fewer surprises

ßusers committed to the success of the project.


Outcomes of a Good Process

ßsoftware engineers and developersßsolving the right problem for the users.ßhave clear, high-level specification of the system to be built.ßsolving a problem that is feasible from all perspectives, notonly technical but humanßcustomers will be able to use the system, like it, makeeffective use of it, and that the system will not haveundesirable side effectsßhave the trust and confidence of the customersßgained knowledge of the domain of the systemßthey have a variety of peripheral or ancillary information aboutthe system useful for making low-level tradeoffs and designdecisions.ßprevented the system from being overly specifiedßhave freedom to make implementation decisions.


Outcomes of a Poor Process

ß buyers and users can be dissatisfiedßdevelopers did not really listen to them, or if the developers dominated

the process and tended to force their own views and interpretations onthe buyers and users.

ß a chaotic development process -- developers are missing importantinformationß requiring additional meetings with the buyers and usersßmay make the wrong decisions or tradeoffsß requirements may change more often,ßgreater need for configuration management, or in delays or wasted effort

in design and implementationß cost and schedule overruns, and sometimes failed or canceled projects.

ß developers are solving the wrong problemßguarantees the failure of the whole project

ß outcomeß loss of money for the company developing or buying the software,ß loss of reputation or credibility for the developersßa decline in the developers’ morale.

CMPSCI520/620



Underlying Difficulties

ßArticulation Problems

ßCommunication Barriers

ßKnowledge and Cognitive Limitations

ßHuman Behavior Issues

ßTechnical Issues


Articulation Problems

ßaware of needs, but unable to articulate them appropriately

ßaware of a need but be afraid to articulate it

ßnot be aware of their needs

ßusers and developers different meanings for common terms

ßusers cannot don’t understand the consequences oralternatives.

ßno single person has the complete picture, no matter howarticulate a user may be

ßdevelopers may not really be listening to the users

ßdevelopers may fail to understand, appreciate, or relate to theusers

ßdevelopers overrule or dominate the users


Communication Barriers

ßusers and developers come from different worlds and havedifferent professional vocabularies and viewsßusers - high level attributes like usability and reliabilityßdevelopers- lower-level attributes like resource utilization,algorithms, and hardware/ software tradeoffs.

ßnatural languages are inherently ambiguousßsocial interactionsßdifferent personality types and different value systems amongpeople.ßcan lead to unexpected difficulties in communicationßSIS exampleß project leader was a high-level person in the company, and he would only

talk to comparably high-level people in the university - deans and vicepresidentsß developers on the project would only talk to the IT & administrative staff in

the university who (they thought) would actually use systemß no one talked to faculty, students, and department staff


Knowledge and Cognitive Limits

ßrequirements elicitor must have adequate domainknowledge

ßno person has perfect memory

ßinformal or intuitive statistics are frequently interpreteddifferently

ßscale and complexity

ßpreconceived approach to the solution of a problem

ß“tunnel vision”

ßimpatience

CMPSCI520/620



Human Behavior Issues

ßconflicts and ambiguities in the roles

ßfear that installation of the software will necessitatechange


Technical Issues

ßcomplexity and social impact

ßchanging requirements

ßchanging software and hardware technologies

ßmany sources of requirements

ßnature or novelty of the system


Requirements Engineering

ß requirements elicitationßthe process through which the customers, buyers, or users ofa software system discover, reveal, articulate, and understandtheir requirements.

ß requirements analysisßthe process of reasoning about the requirements that havebeen elicited; it involves activities such as examiningrequirements for conflicts or inconsistencies, combiningrelated requirements, and identifying missing requirements.

ß requirements specificationßthe process of recording the requirements in one or moreforms, including natural language and formal, symbolic, orgraphical representations; also, the product that is thedocument produced by that process.

ß requirements validationßthe process of confirming with the customer or user of thesoftware that the specified requirements are valid, correct, andcomplete.


Requirements Elicitation

ßoften calledßidentifying, gathering, determining, formulating,extracting, or exposing

ßthese terms have different connotationsßgathering suggests that the requirements are alreadypresent somewhere and we need only bring themtogether

ßformulating suggests that we get to make them up

ßextracting and exposing suggest that the requirementsare being hidden by the users

ß some truth to all of these connotations

CMPSCI520/620



A General Elicitation Procedure

ß identify relevant sources of requirements (the users).ßask them appropriate questions to gain an understanding of

their needs.ßanalyze the gathered information, looking for implications,

inconsistencies, or unresolved issues.ßconfirm your understanding of the requirements with the

users.ßsynthesize appropriate statements of the requirements.ßhow?ßdetailed processesßspecific questions or categories of questions to asßstructured meeting formatsßspecific individual or group behaviors, orßtemplates for organizing and recording information.


Participantsß lead = software engineer (software requirements engineer)ß responsible for producing the requirements specification

ß support = other software engineers, documentation specialists, orclerical staff.ßusers = depends on applicationß IS: sales representatives, order processing personnel, shipping

department personnel, and accounting personnel. Departmentmanagers and company executivesßEmbedded System: design engineers (HW & SW), regulators,

system users, managersßProductivity tools: users of existing packages, market researchersßSIS: students, faculty, advisors, department staff, college staff,

registrars, bursars, financial aid, accountants, financial officers,admissions officers, administrators, laboratory technical staff, IT staff,human resources staff, …

ßno one person knows everything about what a software systemshould doßalways many participants in a successful requirements elicitation

effort


General approach

ßAskingßIdentify the appropriate person, such as the buyer oruser of the software, and ask what the requirements are.

ßObserving and inferring.ßObserve the behavior of users of an existing systemwhether manual or automated), and then infer theirneeds from that behavior.

ßDiscussing and formulatingßDiscuss with users their needs and jointly formulate acommon understanding of the requirements.

ßNegotiating with respect to a standard setßBeginning with an existing or standard set ofrequirements or features, negotiate with users which ofthose features will be included, excluded, or modified.


General approach

ßStudying and identifying problems.ßPerform investigations of problems to identifyrequirements for improving a system.

ßDiscovering through creative processesßFor very complex problems with no obvious solutions,employ creative processes involving developers andusers.

ßPostulatingßWhen there is no access to the user or customer, or forthe creation of an unprecedented product, use creativeprocesses or intuition to identify features or capabilitiesthat the user might want.

CMPSCI520/620



Traditional methods

ßInterviewing customers and domain experts

ßQuestionnaires

ßObservation

ßStudy of documents and software systems


Interviews

ßTutorial interviewßExpert offers potential solutions and alternatives

ßFocused interviewßAnalyst prepares topics but not questions

ßStructured interviewßAnalyst prepares & follows a flexible topic structureßOpen-ended questions

ßClose-ended questions

ßCard sorting, repertory grids

ßTeachback interviewßUsers describe problem solving activity to analyst


Interviews

ßInterviewing customers and domain experts

ßQuestions to be avoidedßOpinionated questions

ßBiased questions

ßImposing questions


questioning techniques

ßscenarioßsystem-specific questions

ßreflects less mature evaluation

ßquestionnaireßmore general items

ßreflects more mature evaluation practices

ßchecklistßdomain-specific

ßreflects more mature evaluation practices

CMPSCI520/620



Scenario

ßa specified sequence of steps involving the use ormodification of the system

ßprovides a means to characterize how well a particulararchitecture responds to the

ßdemands placed on it by those scenarios test what wenormally call modifiability


Scenario usage -- current practice

ßFormßnarrative text

ßStructured text

ßDiagrammatic notation

ßImages

ßAnimations and simulations

ßContentßSystem context

ßSystem interaction

ßSystem internals


Purpose of Scenarios

ßConcretize abstract models

ßScenarios instead of abstract models

ßScenario use with prototypes

ßComplexity reduction

ßAgreement and consistency

ßScenario usage with glossaries

ßReflection on static models


When to use scenarios

ßWhen abstract modeling failsßCost

ßInherent complexity

ßTeam issues

ßIn conjunction with prototypesßCan yield symbiotic results

ßStepsßDevelop scenarios

ßDevelop prototypes

ßValidate prototypes

ßRefine scenarios

CMPSCI520/620



When to use scenarios

ßFor complexity reductionßUse-case approach

ßScenarios become a structuring device

ßFor exception handling & identification

ßFor achieving partial agreementßStakeholders have different goals & interests

ßUse scenarios to drive the agreement process

ßIn conjunction with glossariesßEstablish a common understanding of terms


Questionnaire

ßa list of general and relatively open questions that applyto all systems

ßhow the requirements were generated and documented

ßdetails of the requirements descriptionßuser interface aspects separated from functionalaspects?


Checklist

ßa more detailed set of questions that is developed aftermuch experience evaluating a common (usuallydomain-specific) set of systems.

ßhelp keep a balanced focus on all areas of the system

ßmore focused on particular qualities of the system thanquestionnairesße.g., performance questions in a real-time informationsystemß is the system writing the same data multiple times to disk?

ßhas consideration been given to handling peak as well asaverage loads?


Questionnaires & Observation

ßQuestionnairesßIn addition to interviews

ßClose-ended questionsßMultiple-choice questions

ßRating questions

ßRanking questions

ßObservationßPassive

ßActive

ßCarried for a prolonged period of time

ßPeople tend to behave differently

CMPSCI520/620



Other

ßStudy of documents and software systemsßUse case requirementsßOrganizational documents

ßSystem forms and reports

ßDomain knowledge requirementsßDomain journals and reference books

ßERPS-s


Modern methods

ßPrototyping

ßJoint Application Development (JAD)

ßRapid Application Development (RAD)


simulations, prototypes, etc

ßmay help to create and to clarify the requirements

ßperformance models are an example of a simulation

ßsimulation or prototype may answer an issue raised by aquestioning techniqueße.g., what evidence do you have to support thisassertion?


Prototyping

ßstrategiesßthrow-away prototype

ßevolutionary prototype

ßadvantages

ßusers may be better able to understand and express theirneeds by comparing to an existing or reference system

ßprocessß iterative process of building a prototype and evaluating it withthe users.

ßeach iteration allows the users to understand theirrequirements better, including understanding the implicationsof the requirements articulated in previous iterations.

ßeventually, a final set of requirements can be formulated andthe prototypes discarded.

CMPSCI520/620



Prototyping

ßdistinguish the terms prototype and mock-up,ßA prototype demonstrates behavior of a part of the desiredsystem,ßA mock-up demonstrates the appearance of the desiredsystemßmock-ups of user interfaces are especially common.

ßbeneficial only if the prototype can be built substantially fasterthan the actual systemßprototyping should not be viewed as a euphemism for trial-

and-error programming or “hacking.”ßprototyping is properly used to elicit and understand

requirements, followed by a structured and managed processto build the actual systemßuseful in overcoming articulation problems and

communication barriers.


Cleanroom method

Customer/UserFeedback

Customer

Complete system

Increment 1• Sign on/off• setup

Increment 2• Sign on/off• Setup• Panel navigation

Increment 3• Sign on/off• Setup• Panel navigation• Primary functions Increment 4

• Sign on/off• Setup• Panel navigation• Primary functions• Secondary functions

Requirements

Top Level Specs

IncrementalDevelopment Plan

NewReusedStubbed

Customer

Documents

UML 2 Activity Diagrams 11 - UML & Requirementsadrion/520-f03/PDF-links/11-UML-Reqmt.pdf11 - UML & Requirements ... Activity Diagram Notation ßInitial node ßfilled circle = starting