UML & Requirements UML 2 Activity Diagrams Activity Diagram

CMPSCI520/620

UML 2 Activity Diagrams

ßobject-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development ßtypically used for ßbusiness process modeling 11 - UML & Requirements ßmodeling the logic captured by a single use case or usage scenario ßmodeling the detailed logic of a business rule Rick Adrion ßcould potentially model ßthe internal logic of a complex operation ßfar better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram

UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMP SCI 520/620 FALL 2003 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMP SCI 520/620 FALL 2003

Activity Diagram Notation University enrollment example

ß Decision “Swim lanes” ß Initial node Apply to

ß filled circle = starting point of the ß A diamond with one flow entering and Fill out Universityy diagram, not required several leaving forms x ß Activity final node ß Merge ß A diamond with several flows entering applicant Enroll ß filled circle with a border is the and one leaving, all incoming flows in

[incorrect] seminar ending point, can have zero or must reach this point until processing y more activity final nodes. continues, unless otherwise noted ß Activity ß Partition ß also called swimlanes, indicating Imput Must be on ß rounded rectangles represent forms Input [not on list] activities, may be physical or who/what is performing the activities applicant list of applicants, Select electronic ß Sub-activity indicator info but not in system applicant ß rake in the bottom corner of an activity from list ß Flow/edge indicates that the activity is described registrar ß arrows on the diagram by a more finely detailed activity ß Fork diagram. ß Flow final [correct] [not on match list] [on match list] ß A black bar with one flow going ß circle with the X through it, process into it and several leaving it, stops at this point. parallel activity. Check [on list] Create ß Use case Display applicant student ß Join ß non-official? indication that an included create student list ß A black bar with several flows use case is being invoked. screen entering it and one leaving it, Search [no match] denotes the end of parallel system for processing. applicant Display ß Condition list of ß a guard which must evaluate to [potential matches] matches true in order to traverse the node Scott W. Ambler , Copyright 2003 www.agilemodeling.com/ Scott W. Ambler , Copyright 2003 www.agilemodeling.com/ UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMP SCI 520/620 FALL 2003 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMP SCI 520/620 FALL 2003

”Rick Adrion 2003 (except where noted) 1 CMPSCI520/620

University enrollment example University enrollment example

Use-case signal B: Forms not filled out course of action G: Not eligible to enroll Apply to University pin [incorrect] [not on list]

[on list] H Verify Create applicant student Display is on list Fill out Imput create Input forms forms applicant student info See if screen applicant Is in system [no match] Basic Course

Possible [not on match list] Security Alternative Risk [potential matches] Use-case time triggered Perform Display list of Security matches Check [on match list] Exisiting Use Case F: Student may be in System

When to Use Activity Diagrams Activity Diagram Modeling Tips

ßUse activity diagrams when the behavior you are ßControl flow and object flow are not separate. Both are modeling ... modeled with state transitions. ßdoes not depend much on external events. ßDashed object flow lines are also control flow. ßmostly has steps that run to completion, rather than being interrupted by events. ßYou can mix state machine and control/object flow constructs on the same diagram (though you probably ßrequires object/data flow between steps. do not want to). ßis being constructed at a stage when you are more concerned with which activities happen, rather than which objects are responsible for them (except partitions possibly).

”Rick Adrion 2003 (except where noted) 2 CMPSCI520/620

Wrap Up: Activity Diagrams Statechart modeling

ßUse Activity Diagrams for applications that are primarily ßCaptures dynamic changes of class states – the life control and data-driven, like business modeling … history of the class … rather than event-driven applications like embedded ßThese dynamic changes describe typically the behavior systems. of an object across several use cases ßState of an object – designated by the current values of ßActivity diagrams are a kind of state machine until UML the object's attributes 2.0 … ßStatechart Diagram – a bipartite graph of … so control and object/data flow do not have separate ßstates (rounded rectangles) and semantics. ßtransitions (arrows) caused by events ßThe concepts of states and events are the same concepts that we know from Activity Diagrams – the difference is that “the states of the activity graph represent the states of executing the computation, not the states of an ordinary object”

Types of Events Types of Events

ßUML defines 4 kinds of events ßEvents are occurrences of interest that have both ßSignal Event ßLocation ßAsynchronous signal received ßAbsolute time of occurrence ße.g. evFlameOn ßSignal events associate with Signals ßCall Event ßA Signal is a specification of an asynchronous ßoperation call received communication between structural elements (e.g. ße.g. op(a,b,c) objects) ßChange Event ßOne type of Signal is Exception ßchange in value occurred ßTime Event ßRelative time elapse ßAbsolute time arrived ße.g. tm(PulseWidthTime)

”Rick Adrion 2003 (except where noted) 3 CMPSCI520/620

States and transitions Statecharts & Activity Diagrams

ßObjects change values of their attributes but not all such changes cause state transitions ßWe construct state models for classes that have interesting 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

Heinrich Hussmann

States and transitions Statechart Diagram

ß Normally attached to a class, but can be attached to other modeling concepts, e.g. a use case ß When attached to a class, the diagram determines how 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

Heinrich Hussmann

”Rick Adrion 2003 (except where noted) 4 CMPSCI520/620

Statecharts Statechart notation

ß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 a state

Example Nested submachines

”Rick Adrion 2003 (except where noted) 5 CMPSCI520/620

Implementation diagrams Requirements Process & Products

Market Analysis Systems Analysis Market Needs Business Needs Business Planning System Requirements Component Diagram Systems Engineering

Deployment Diagram

Requirements Analysis Requirements Definition Requirements Definition Requirements Document System Specification Requirements Specification

Behavioral Specification System Specification Specification Functional Specification Specification Document Requirements Specification Heinrich Hussmann

System Planning Approaches

ßBusiness strategy ßSWOT ßTop-down classification, ranking and selection of projects ßSmall organizations based on: mission statement, internal strengths and ßLarge organizations weaknesses, external opportunities and threats, objectives, goals, strategies, and policies ßApproaches ßVCM ßStrength, Weaknesses, Opportunities, Threats (SWOT) ßLook at “value chain” – from raw materials to final products sold and shipped to customers and identify critical areas ßValue Chain Model (VCM) where IT can transform organization’s value chain ßBusiness Process Re-Engineering (BPR) ßBPR ßAimed at radical redesign of business processes, based on ßInformation Systems Architecture (ISA) business process”ownership,” and horizontally cross-cutting ßEffectiveness vs. efficiency processes with end at points of contact with customers. IT support enables BPR ßISA ßA neutral architectural framework with stakeholders (planner, owner, designer, builder, subcontractor) and activities(what, how, where, who, when, why)

”Rick Adrion 2003 (except where noted) 6 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 definition process.

Source of requirements Requirements identification

ßelicited from people or derived from system requirements ßSoftware needs -- Context analysis ßdocuments why software is to be created and why certain technical, operational, and economic feasibilities establish boundary conditions ßElicitation from people ßDeriving from system planning requirements ßTask analysis to develop user interface

”Rick Adrion 2003 (except where noted) 7 CMPSCI520/620

More steps Requirements representation

ßIdentification of software development constraints ßUse of models ßCosts, hardware/software, reliability, portability ßA good model: ßRequirements analysis ßReduces the amount of complexity that must be comprehended at one time. ßAssessment of potential problems ßIs inexpensive to build and modify compared to the real ßClassification of requirements mandatory, desirable, and thing. non-essential ßFacilitates the description of complex aspects of the real ßEvaluation of feasibility and risks thing. ßRoles for prototyping ßprototype is not a substitute for a thorough written specification ßa system can be captured in a prototype

More steps Software Requirement Products

ßRequirements communication ßRequirements definition ßPresent to stakeholders for review ßFunctional ßPreparation for validation of software requirements ßNon-functional ßEstablish criteria ßInverse ßIdentify techniques to be used ßDesign & implementation constraints ßManaging the requirements definition process definition ßRequirement documents process. ßStandards ßa major project management challenge. ß“C-requirements” ßan application that must support five different classes of ß“D-requirements” users with significantly different expectations could easily involve a requirements definition process that is five times more difficult than the corresponding process for a homogeneous group

”Rick Adrion 2003 (except where noted) 8 CMPSCI520/620

Customer/Developer Outcomes of a Good Process

ßObjectives ßThe buyers or users ßRanking of attributes ßoften begin with only a vague idea of what they really need ßKey contents and with little idea of what software technology might offer. ß“C-requirements” ßa good process helps them explore and fully understand their ß Functionality requirements ß Information definitions ß separation of what they want and what they need ß Critical non-functional requirements ß constraints that might be imposed on the system by technology, ß Critical design constraints organizational practices or government regulations. ß Acceptance criteria ß understand alternatives, both technological and procedural, that ß“D-requirements” might be considered in the proposed system ß Functionality ß understand the tradeoffs ß Information definitions ßa good understanding of the implications of their decisions ﬁ ß Interfaces to external systems ß fewer surprises ß Critical non-functional requirements ß users committed to the success of the project. ß Critical design constraints ß Acceptance criteria and tests

Outcomes of a Good Process Outcomes of a Poor Process

ßsoftware engineers and developers ß buyers and users can be dissatisfied ßsolving the right problem for the users. ß developers did not really listen to them, or if the developers dominated the process and tended to force their own views and interpretations on ßhave clear, high-level specification of the system to be built. the buyers and users. ßsolving a problem that is feasible from all perspectives, not ß a chaotic development process -- developers are missing important only technical but human information ßcustomers will be able to use the system, like it, make ß requiring additional meetings with the buyers and users effective use of it, and that the system will not have ß may make the wrong decisions or tradeoffs undesirable side effects ß requirements may change more often, ßhave the trust and confidence of the customers ß greater need for configuration management, or in delays or wasted effort in design and implementation ßgained knowledge of the domain of the system ß cost and schedule overruns, and sometimes failed or canceled projects. ßthey have a variety of peripheral or ancillary information about ß developers are solving the wrong problem the system useful for making low-level tradeoffs and design ß guarantees the failure of the whole project decisions. ß outcome ßprevented the system from being overly specified ß loss of money for the company developing or buying the software, ßhave freedom to make implementation decisions. ß loss of reputation or credibility for the developers ß a decline in the developers’ morale.

”Rick Adrion 2003 (except where noted) 9 CMPSCI520/620

Underlying Difficulties Articulation Problems

ßArticulation Problems ßaware of needs, but unable to articulate them appropriately ßCommunication Barriers ßaware of a need but be afraid to articulate it ßKnowledge and Cognitive Limitations ßnot be aware of their needs ßHuman Behavior Issues ßusers and developers different meanings for common terms ßusers cannot don’t understand the consequences or ßTechnical Issues alternatives. ßno single person has the complete picture, no matter how articulate a user may be ßdevelopers may not really be listening to the users ßdevelopers may fail to understand, appreciate, or relate to the users ßdevelopers overrule or dominate the users

Communication Barriers Knowledge and Cognitive Limits

ß users and developers come from different worlds and have ßrequirements elicitor must have adequate domain different professional vocabularies and views knowledge ßusers - high level attributes like usability and reliability ßdevelopers- lower-level attributes like resource utilization, ßno person has perfect memory algorithms, and hardware/ software tradeoffs. ßinformal or intuitive statistics are frequently interpreted ß natural languages are inherently ambiguous differently ß social interactions ßscale and complexity ßdifferent personality types and different value systems among people. ßpreconceived approach to the solution of a problem ßcan lead to unexpected difficulties in communication ß“tunnel vision” ßSIS example ß project leader was a high-level person in the company, and he would only ßimpatience talk to comparably high-level people in the university - deans and vice presidents ß 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

”Rick Adrion 2003 (except where noted) 10 CMPSCI520/620

Human Behavior Issues Technical Issues

ßconflicts and ambiguities in the roles ßcomplexity and social impact ßfear that installation of the software will necessitate ßchanging requirements change ßchanging software and hardware technologies ßmany sources of requirements ßnature or novelty of the system

Requirements Engineering Requirements Elicitation

ßrequirements elicitation ßoften called ßthe process through which the customers, buyers, or users of a software system discover, reveal, articulate, and understand ßidentifying, gathering, determining, formulating, their requirements. extracting, or exposing ßrequirements analysis ßthese terms have different connotations ßthe process of reasoning about the requirements that have been elicited; it involves activities such as examining ßgathering suggests that the requirements are already requirements for conflicts or inconsistencies, combining present somewhere and we need only bring them related requirements, and identifying missing requirements. together ßrequirements specification ßthe process of recording the requirements in one or more ßformulating suggests that we get to make them up forms, including natural language and formal, symbolic, or ßextracting and exposing suggest that the requirements graphical representations; also, the product that is the document produced by that process. are being hidden by the users ßrequirements validation ß some truth to all of these connotations ßthe process of confirming with the customer or user of the software that the specified requirements are valid, correct, and complete.

”Rick Adrion 2003 (except where noted) 11 CMPSCI520/620

A General Elicitation Procedure Participants

ßidentify relevant sources of requirements (the users). ß lead = software engineer (software requirements engineer) ßask them appropriate questions to gain an understanding of ß responsible for producing the requirements specification their needs. ß support = other software engineers, documentation specialists, or clerical staff. ßanalyze the gathered information, looking for implications, ß users = depends on application inconsistencies, or unresolved issues. ß IS: sales representatives, order processing personnel, shipping ßconfirm your understanding of the requirements with the department personnel, and accounting personnel. Department users. managers and company executives ßsynthesize appropriate statements of the requirements. ß Embedded System: design engineers (HW & SW), regulators, ßhow? system users, managers ß Productivity tools: users of existing packages, market researchers ßdetailed processes ß SIS: students, faculty, advisors, department staff, college staff, ßspecific questions or categories of questions to as registrars, bursars, financial aid, accountants, financial officers, ßstructured meeting formats admissions officers, administrators, laboratory technical staff, IT staff, human resources staff, … ßspecific individual or group behaviors, or ß no one person knows everything about what a software system ßtemplates for organizing and recording information. should do ß always many participants in a successful requirements elicitation effort UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMP SCI 520/620 FALL 2003 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMP SCI 520/620 FALL 2003

General approach General approach

ßAsking ßStudying and identifying problems. ßIdentify the appropriate person, such as the buyer or ßPerform investigations of problems to identify user of the software, and ask what the requirements are. requirements for improving a system. ßObserving and inferring. ßDiscovering through creative processes ßObserve the behavior of users of an existing system ßFor very complex problems with no obvious solutions, whether manual or automated), and then infer their needs from that behavior. employ creative processes involving developers and ßDiscussing and formulating users. ßDiscuss with users their needs and jointly formulate a ßPostulating common understanding of the requirements. ßWhen there is no access to the user or customer, or for ßNegotiating with respect to a standard set the creation of an unprecedented product, use creative ßBeginning with an existing or standard set of processes or intuition to identify features or capabilities requirements or features, negotiate with users which of that the user might want. those features will be included, excluded, or modified.

”Rick Adrion 2003 (except where noted) 12 CMPSCI520/620

Traditional methods Interviews

ßInterviewing customers and domain experts ßTutorial interview ßQuestionnaires ßExpert offers potential solutions and alternatives ßObservation ßFocused interview ßStudy of documents and software systems ß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 questioning techniques

ßInterviewing customers and domain experts ßscenario ßQuestions to be avoided ßsystem-specific questions ßOpinionated questions ßreflects less mature evaluation ßBiased questions ßquestionnaire ßImposing questions ßmore general items ßreflects more mature evaluation practices ßchecklist ßdomain-specific ßreflects more mature evaluation practices

”Rick Adrion 2003 (except where noted) 13 CMPSCI520/620

Scenario Scenario usage -- current practice

ßa specified sequence of steps involving the use or ßForm modification of the system ßnarrative text ßprovides a means to characterize how well a particular ßStructured text architecture responds to the ßDiagrammatic notation ßdemands placed on it by those scenarios test what we ßImages normally call modifiability ßAnimations and simulations ßContent ßSystem context ßSystem interaction ßSystem internals

Purpose of Scenarios When to use scenarios

ßConcretize abstract models ßWhen abstract modeling fails ßScenarios instead of abstract models ßCost ßScenario use with prototypes ßInherent complexity ßComplexity reduction ßTeam issues ßAgreement and consistency ßIn conjunction with prototypes ßScenario usage with glossaries ßCan yield symbiotic results ßReflection on static models ßSteps ßDevelop scenarios ßDevelop prototypes ßValidate prototypes ßRefine scenarios

”Rick Adrion 2003 (except where noted) 14 CMPSCI520/620

When to use scenarios Questionnaire

ßFor complexity reduction ßa list of general and relatively open questions that apply ßUse-case approach to all systems ßScenarios become a structuring device ßhow the requirements were generated and documented ßFor exception handling & identification ßdetails of the requirements description ßFor achieving partial agreement ßuser interface aspects separated from functional ßStakeholders have different goals & interests aspects? ßUse scenarios to drive the agreement process ßIn conjunction with glossaries ßEstablish a common understanding of terms

Checklist Questionnaires & Observation

ßa more detailed set of questions that is developed after ßQuestionnaires much experience evaluating a common (usually ßIn addition to interviews domain-specific) set of systems. ßClose-ended questions ßhelp keep a balanced focus on all areas of the system ßMultiple-choice questions ßmore focused on particular qualities of the system than ßRating questions questionnaires ßRanking questions ße.g., performance questions in a real-time information ßObservation system ßPassive ßis the system writing the same data multiple times to disk? ßActive ßhas consideration been given to handling peak as well as ßCarried for a prolonged period of time average loads? ßPeople tend to behave differently

”Rick Adrion 2003 (except where noted) 15 CMPSCI520/620

Other Modern methods

ßStudy of documents and software systems ßPrototyping ßUse case requirements ßJoint Application Development (JAD) ßOrganizational documents ßRapid Application Development (RAD) ßSystem forms and reports ßDomain knowledge requirements ßDomain journals and reference books ßERPS-s

simulations, prototypes, etc Prototyping

ßmay help to create and to clarify the requirements ßstrategies ßperformance models are an example of a simulation ßthrow-away prototype ßsimulation or prototype may answer an issue raised by a ßevolutionary prototype questioning technique ßadvantages ße.g., what evidence do you have to support this ßusers may be better able to understand and express their needs by comparing to an existing or reference system assertion? ßprocess ßiterative process of building a prototype and evaluating it with the users. ßeach iteration allows the users to understand their requirements better, including understanding the implications of the requirements articulated in previous iterations. ßeventually, a final set of requirements can be formulated and the prototypes discarded.

”Rick Adrion 2003 (except where noted) 16 CMPSCI520/620

Prototyping Cleanroom method

ßdistinguish the terms prototype and mock-up, Requirements ßA prototype demonstrates behavior of a part of the desired Customer Customer system, Top Level Specs ßA mock-up demonstrates the appearance of the desired system Incremental Development Plan Customer/User ß mock-ups of user interfaces are especially common. Feedback Complete system ßbeneficial only if the prototype can be built substantially faster than the actual system ßprototyping should not be viewed as a euphemism for trial- Increment 1 and-error programming or “hacking.” • Sign on/off • setup ßprototyping is properly used to elicit and understand requirements, followed by a structured and managed process Increment 2 Increment 3 to build the actual system • Sign on/off • Sign on/off • Setup • Setup • Panel navigation • Panel navigation ßuseful in overcoming articulation problems and • Primary functions Increment 4 New • Sign on/off communication barriers. Reused • Setup • Panel navigation Stubbed • Primary functions • Secondary functions

”Rick Adrion 2003 (except where noted) 17