UML and Systems Analysis

1. UML and Systems Analysis MIS3502: Application Integration and Evaluation Paul Weinberg weinberg@temple.edu Presentation by David Schuff and Paul Weinberg

2. Review: What is Systems Analysis and Design? • Systems Analysis • Analysis of complex, large-scale systems and the interactions within those systemshttp://en.wikipedia.org/wiki/Systems_analysis • Systems Design • The process of defining the hardware and software architectures, components, models, interfaces, and data for a computer system to satisfy specified requirementshttp://en.wikipedia.org/wiki/Systems_design Notice that they are not the same!

3. Basically… • Systems Analysis is the process of modeling the problem • Requirements-oriented • What should we do? • Systems Design is the process of modeling a solution • Functionality-oriented • How should we do it?

4. Why model? • Creating a blueprint for an application • Before you start coding • The idea is to minimize having to go back and make changes later

5. Why consider SAD in a programming course? The business analysts The development team Analysis Design Development

6. What this means • A developer must be able to turn the design into code • But a good analyst should be able to understand all parts of system development • Conduct an analysis • Develop a design • Implement the design (coding)

7. Example: Bjork’s ATM example • An Example of Object Oriented Design, An ATM Simulation, Russell Bjork • http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/

8. What we’ll look at… Analysis Models Design Models Class name Customer Attributes name Operations findName() Use case diagrams Design class diagrams :Controller :Customer :Order Use case descriptions Activity diagrams Interaction diagrams All diagrams adapted from “Systems Analysis and Design in a Changing World”, 3rd Edition Satzinger, Jackson, Burd, Thompson Publishing, 2004.

9. Problem Statement • What is the application supposed to accomplish? • Use words, not code • Be as descriptive as possible • Potential sources of information • Forms, reports • Engineering drawings • Real world object specifications • Interviews

10. Problem statement for ATM application • Services one customer at a time • Must be able to handle 10 customers an hour • Customer inserts ATM card and enters PIN to begin • Transactions • Cash withdrawals --- in $20 increments • Deposits • Transfers • Balance inquiries • Immediate transaction validation with the bank • Standard error procedures • Pin error, rejection due to inadequate balance • Reports

11. Use Case Diagram Session • Use case: sequence of events that represents an interaction between the user and the system Customer (actor) Bank (actor) Cash Withdrawal Deposit Transfer Invalid PIN Partial list of use cases from Bjork example

12. Narrative Problem Statement - Use Cases • A use case is a logical sequence of events from the users first interaction, to the desired outcome. • For each use scenario, and each user (actor) . . . a use case describes • The services the system provides to the user • The sequence of events • The desired outcome • Users of systems can be • people • organizations • other systems

13. A Use Case for the ATM From the Bjork website: System startup . . . User: System operator Services: Load cash dispenser, start ATM "The system is started when the operator turns the switch on the panel to 'on'. The operator will be asked to enter the amount of money in the cash dispenser . . . "

14. Object Classes Are . . . • Tangible Things • Airplane, ATM, person • Roles • Professor, student • Incidents and interactions • Purchase, withdrawal, flight • Specifications • Aircraft characteristics: Weight, wingspan, max speed Notice that many objects are not physical. (e.g. transactions, like a purchase, are not physical)

15. Identifying Potential Object Classes • Identify noun-phrases (nouns and related adjectives) in the narrative descriptions • Eliminate duplicates (including plurals of items in the list) • Eliminate state information (e.g. terms like "completion") • Eliminate synonyms • Assure that the classes are abstractions that a user would recognize (Not implementation tools) • Determine whether actors not in the class list should be. Check to see if other actors need their services.

16. Naming Objects • Avoid roles or states in the names (e.g. ATM dispensing cash)

17. Testing Potential Classes • Objects instantiated from the classes must have the same set of attributes . . . • Dog licenses and vehicle licenses cannot be in the same class • However, they can both be derived from the same class • Objects must have attributes • Social security number is not a class, it is only a name • Social security account is a class • "Or" must be avoided in defining the class • The objects formed from a class must be more than a list . . . The class must be definable

18. Static Class Relationships • Static relationships • Inheritance: Class a is derived from class b • Association, e.g. President runs an airline There are many students in one University There may be many Universities associated with one student. • Aggregation (Special case of association): class a "is comprised of" Class b, e.g. A building has rooms A course has 5 sections Associations and aggregations are coded the same way.

19. Static Class Relationships in the Unified Modeling Language (UML) Aggregation Inheritance University Animal School Dog Cat

20. Static Class Relationships in the Unified Modeling Language (UML) - Continued Associations * 1 Section Professor * * Course 1 * • Association relationships possible: • 1 * --- One to many • * * --- Many to many • 1 1 --- One to one • What are the specific associations in this example?

21. Static Class Relationships in the Unified Modeling Language (UML) - Continued Person Inheritance and Associations in the same diagram * 1 Section Professor * * Course 1 *

22. Exercise • Consider the following list of ATM classes • Are there any inheritance relationships? • Do any classes contain other classes? • Are there any other associations --- what are they? Draw a UML representation of the relationships. Review: Bjork's UML definition.

23. Completing the Static Class Definitions • Determine and define attributes of each class Give an example of a field belonging to the cash dispenser.

24. Dynamic class behavior (public methods) • State of an object --- Values of all attributes at a specific time • Methods --- • Respond to events • Handle requests from other objects • Send requests to other objects by calling their methods • May return values --- Accessor methods (i.e. have a non-void return value) • May modify state of an object --- Mutator methods (i.e. may have a void return value)

25. A first step in establishing public methods • Start with a use case or state diagram • Construct a sequence of steps required of objects to complete the sequence of events associated with each use case. • For each step • Service description • Object requesting the service (client) • Object fulfilling the service • Next object (or objects) involved in completing the sequence • Identify methods for each object to perform the services.

26. Sequence of Steps for a Withdrawal • Withdrawal transaction • ATM --> Card Reader checkForCardInserted() • ATM --> Session startSession() • Session --> Keyboard readPin() • Session --> Keyboard readMenuChoice() • Session --> WithDrawalTransactiongetTransactionSpecifics() • WithDrawalTransaction --> Bank initiateWithdrawal (cardNumber,PIN,ATM number, serial, from, amount) Some of these steps require instantiation of new objects by adding them to ArrayLists . . . others do not. What is an example of this? Following the state diagram for a session, what's next?

27. Next step: From model to program . . . • Inheritance relationships coded as : • Relationships • 1:1 becomes instantiation of the related class • 1:* becomes instantiation of a ArrayList or array containing the related class • Public Methods are determined from each sequence of steps for major uses. • The methods are associated with specific classes. • Additional implementation classes • GUI design and classes • Data base and other technology-related classes

28. Shows the attributes and methods of each class Get the object names and attributes from the noun-phrase analysis What is the object? Get the methods from the activity diagram What should it do? Design class diagrams

29. Activity diagram Customer ATM Bank Choose deposit Ask which type of account • Show which activities occur during a use case • This is for the deposit use case • The customer initiates the transaction Choose account type Ask deposit amount Choose deposit amount Send customer information to bank Incorrect PIN? yes no Incorrect PIN exception Approve transaction no Transaction failed yes Credit customer account Transactioncompleted

30. Working from the design class diagram • The DepositTransaction class will have • Two attributes • Four methods • We can tell from this what methods the class will have but not what they do • Refer to the use cases, activity diagrams, and interaction diagrams for detail

31. Interaction Diagrams • Show how the objects in the application “use” each other • Which methods are called • What data is returned

32. ATM application:Deposit Use Case (self) getTransactionSpecificsFromCustomer() Customer :ATM :Session :DepositTransaction :Bank Session(session, atm, bank) DepositTransaction(session, atm, bank) sendToBank() (approval) checkIfCashAvailable(amount) (confirmation) initiateDeposit(account, amount) (confirmation) finishApprovedTransaction() (confirmation)

33. Fitting everything together Use case diagram List of all use cases in the application Use case descriptions Textual description of what happens in each use case Activity diagram Picture of the activities described in each use case Design class diagrams List of all methods and attributes in each object Interaction diagram Diagram of how the objects work together for each use case Scenarios Objects

34. Integration and UML: Web Services • We’ll be working with this application later in the course • It uses the MSN Live Search web service to search the web • Microsoft’s web service is a distributed object

35. Things to think about • What if you have to code something not accounted for in the design diagrams? • Does the diagram have to match the code exactly? • What does it mean when… • …additional detail is required? • …specified methods go unused? • …different sequencing is required?