1. CSC480 Software Engineering Lecture 8-9 September 20, 2002

2. CSC480 - Software Engineering2 9/20/2002 Topics Projects 2&3 review Unified Process Analysis: bridging the gap between requirement and design UML diagrams

3. CSC480 - Software Engineering3 9/20/2002 UP Phases & Workflows

4. CSC480 - Software Engineering4 9/20/2002 UP Phases & Milestones

5. CSC480 - Software Engineering5 9/20/2002 Req’t Workflow – overview The essential purpose is to aim development toward the right system. Achieved by describing the requirements well enough so that an agreement can be reached between customer and the system developers. Requirements must be written in the language of the customer.

6. CSC480 - Software Engineering6 9/20/2002 Req’t Workflow – participants Participants should include  Customers – domain experts, end users  Development team – architects, analyst The users don’t know what they require  Fail to give a whole picture of the system  Don’t know what can be implemented  Don’t know how efficient the system could be  Don’t know how to express req’ts precisely

7. CSC480 - Software Engineering7 9/20/2002 Requirement Capture The workflow includes the following steps which are not actually performed separately:  List candidate requirements  Understand system context Domain model Use cases  Capture functional requirements  Capture nonfunctional requirements

8. CSC480 - Software Engineering8 9/20/2002 List Candidate Requirements Gather desired features from stakeholders  Name, brief description/definition.  A set of planning values: Status (proposed, approved, validated) Estimated cost of implementation (in terms of resource types, man-hours) Priority (critical, important, ancillary) Associated level of risk in implementing the feature (critical, significant, or ordinary) Artifacts  Feature list

9. CSC480 - Software Engineering9 9/20/2002 Understand System Context Domain modeling  Expressing important context concepts as domain objects, and links to one another  Develops a glossary of terms for team communication Business modeling  Describing the business process  A superset of domain modeling Artifacts  Business or domain model

10. CSC480 - Software Engineering10 9/20/2002 Capture Functional Req’ts Use cases  To the user, a use case is a way of using the system  A user needs a number of use cases (G)UI is an adjunct to use cases  specifying the way a system looks to users when a use case is performed Artifacts  Use-case model

11. CSC480 - Software Engineering11 9/20/2002 Capture Nonfunctional Req’ts Address required system properties in the use cases to which they apply, as special req’ts Environmental/implementation constraints Performance Platform dependency Maintainability reliability Artifacts  Supplementary requirements

12. CSC480 - Software Engineering12 9/20/2002 Sample App – ATM transactions Entity objects DB broker Presentation Domain objects Control objects Security manager Storage Service objects Application Logic Layers in a typical O-O information system DB

13. CSC480 - Software Engineering13 9/20/2002 Feature List & Domain Model Feature List - see Sample App 2 Need Statement Domain model Transaction DepositTransferWithdraw Account Entity objects Control objects

14. CSC480 - Software Engineering14 9/20/2002 The GUI Objects

15. CSC480 - Software Engineering15 9/20/2002 Build a Use Case Model Use case model represents functional requirements Actors are the environment of the system Use cases specify the system Deposit money Transfer btw accounts Withdraw money

16. CSC480 - Software Engineering16 9/20/2002 Use Case – a definition A use case specifies a sequence of actions, including variations, that the system can perform and that can yields an observable result of value to a particular actor.

17. CSC480 - Software Engineering17 9/20/2002 Use Case Specification

18. CSC480 - Software Engineering18 9/20/2002 Represent Complex Use Case Some arrowed links may have condition associated with them.

19. CSC480 - Software Engineering19 9/20/2002 Sample Use Case - Withdraw Money The sequence of actions for the main path through this use case is  The Bank Customer identifies himself/herself  The Bank Customer chooses from which account to withdraw money and specifies how much to withdraw  The system deducts the amount from the account and dispenses the money

20. CSC480 - Software Engineering20 9/20/2002 Requirement Tracing A Requirement Traceability Matrix

21. CSC480 - Software Engineering21 9/20/2002 Analysis – overview Analyze requirements by refining and structuring them Essential purposes include  Yield a more precise specification of the req’ts  Described in developers’ language better for reasoning about system internals  Well-structured for changes and maintenance  First-cut of design (yet not so overwhelming)

22. CSC480 - Software Engineering22 9/20/2002

23. CSC480 - Software Engineering23 9/20/2002 Analysis Class Diagrams Boundary objects  Objects with which actors will be interacting Entity objects  Info holders, from domain model  outlive use case execution Control objects  Objects that embody application logic

24. CSC480 - Software Engineering24 9/20/2002 Analysis Diagram Rules Actors can talk only to boundary objects Boundary objects can talk only to controllers and actors Entity objects can only talk to controllers Controllers can talk to both boundary and entity objects, but not to actors

25. CSC480 - Software Engineering25 9/20/2002 Use-Case & Analysis Models

26. CSC480 - Software Engineering26 9/20/2002 Withdraw Money

27. CSC480 - Software Engineering27 9/20/2002 Analysis Workflow Architectural analysis  Identify packages  Identify obvious classes  Identify common special requirements Analyze use cases  Identify classes whose objects are used here  Distribute the behavior to interacting objects  Capture special requirements

28. CSC480 - Software Engineering28 9/20/2002 Analysis Workflow – continued Analyze classes  Identify and update the responsibilities  Identify and update attributes and relationships  Capture special requirements on them Analyze packages  Ensure packages are independent  Ensure each package fulfill its purpose  Describe dependencies

29. CSC480 - Software Engineering29 9/20/2002 Design Class Diagram

30. CSC480 - Software Engineering30 9/20/2002 Sequence Diagram

31. CSC480 - Software Engineering31 9/20/2002 Package Classes into Subsystems

32. CSC480 - Software Engineering32 9/20/2002 Deploy A Distributed System