Analysis Yaodong Bi

Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases – Precisely describe use cases for the developers with more formal notations – Deal with redundancies among use cases by looking into the possible internal structure of use cases. – Use-case refinement

Use Case Model and Analysis Model USE CASE MODEL Language of the customer External view of the system Structured by use cases Used as a contract Conflicts, redundancies, etc Capture of functionality Define used cases ANALYSIS MODEL Language of the developer Internal view of the system Structured by stereotypical classes and packages Used for the developers Conflicts, redundancies removed Realization of functionality Define use case realization

Analysis vs. Design ANALYSIS – A precise and detailed understanding of the requirements for developers – A structure of the requirements that can be used as an input to the shaping of the system – Using stereotype classes – At abstract/conceptual level – One element in analysis DESIGN – Performance and distribution – How to optimize an procedure – How to use a third-party system efficiently – How to use a language properly – Real classes – At implementation level – Five elements in design

Why Analysis Analysis result may be used for planning for design and implementation Analysis model may provide an overview of the system that may be harder to get by studying the results of design and implementation Analysis model offers a conceptual, precise and unified view of alternatives implementations (ex. In fault tolerance) Developers can understand legacy systems without having to delve into the detail of their design an implementation.

Artifacts of Analysis Analysis model – A hierarchy of analysis packages containing analysis classes and use-case realizations Analysis classes – Handling functional requirements and postponing nonfunctional requirements, – Concepts in the problem domain context – Related to each other in conceptual relationships like generalization, instead physical like navigability – Often not define operations and their signatures

Artifacts of Analysis -2 Three basic stereotypes of analysis classes( p183 Fig 8.5 ): – Boundary classes (p184, Fig 8.6) Model interaction between the system and its actors Isolate interface changes to boundary class(es) Don’t describe how interactions are physically realized – Entity classes (p185 Fig. 8.7) Model information that is long-lived and often persistent. Derived directly from business entity classes Not every business entity class is mapped to an analysis entity class Isolate information changes to entity classes

Artifacts of Analysis -3 Three basic stereotypes of analysis classes ( p183 Fig 8.5 ): – Control classes(p185, Fig 8.8) Model coordination,sequencing, transactions, and control of other objects Model complex derivations and calculations, such as business logic Do not encapsulate issues related to actor interactions and long-lived, persistent information

Artifacts of Analysis - 4 Use-Case Realization – Analysis – Class diagrams (p187, Fig. 8.11) participating analysis classes and their relationship – Interaction diagrams (p188, Fig. 8.12) realizations of use cases – Flow of Events – Analysis (p189, example) Textual description of diagrams like collaboration diagrams – Special requirements (p190, example) Textual description of nonfunctional requirements

Artifacts of Analysis -5 Analysis packages (p198, Fig 8.20, 8.21) – Organize the artifacts of analysis in manageable pieces – Created based on functional requirements, not performance requirements – Separate analysis concerns – They are likely to become subsystems on the top two application layers in the design model – Service packages, each contains a set of functionally related actions, and a customer may buy a mix of services

Artifacts of Analysis -6 Architecture Description – Architectural view of the analysis model – Contains the following: Analysis packages and their relationships Key analysis classes: important boundary classes, entity classes, and control classes Use-case realizations for important and critical functionality

Activities of Analysis Architectural Analysis – Identify analysis packages, their relationships, obvious analysis classes, and common special requirements Analyze Use Cases – Identify analysis classes, their relationships, special requirements Analyze Classes – Identify responsibilities, attributes, relationships, special requirements of analysis classes, Analyze Packages – Check packages’ coupling, responsibility, and dependencies

Activities of Analysis - 2 Architectural Analysis – Identify analysis packages Allocate use-cases to support a business process, an actor, and coherently related use-cases (p198, ex.) Handle commonality among analysis packages (p199) Identify service packages (p200, Fig 8.22; p201, Fig 8.23) Define analysis package dependencies (p202, Fig 8.24) – Identify obvious entity classes (p202, example) – Identify common special requirements (p203, ex.)

Activities of Analysis -3 Analyze use cases – Purpose Identify the analysis classes whose objects are needed to perform the use case Distribute the behavior of the use-case to analysis objects Capture special requirements on the realization of the use case – Steps Identify analysis classes Describe analysis object interactions Capture special requirements

Activities of Analysis -4 Analyze use cases -2 – Identify analysis classes (p187 fig 8.11) Identify entity classes for information needed in realization Identify one central boundary class for each human actor as the primary window in the interface Identify one primitive boundary class for each entity class as logical objects of the interface Identify one central boundary class for each external system actor as the communication interface Identify one control class for the control and coordination of the use-case realization (control may be in the boundary class when the actor handles most the control) Use class diagram to show the relationships among them

Activities of Analysis -5 Analyze use cases - 3 – Describe analysis object interactions -1 Use collaboration diagrams to represent analysis classes (objects), actors, and their links. (p188, Fig 8.12) One collaboration diagram for each different flow or subflow. A collaboration diagram starts from the beginning of the flow and then going through the flow one step at a time. Each analysis should participate in at least one collaboration diagram

Activities of Analysis -6 Analyze use cases - 4 – Describe analysis object interactions -2 The links in the collaboration diagram should be an instance of associations between analysis classes in class diagram (p 187 Fig 8.11 and Fig 8.12) Textual description may complement the diagram in flow of event (p189, ex.) – Capture special requirements Capture all nonfunctional requirements for each use-case realization, they will de dealt with in design and implementation (p207, ex.)

Activities of Analysis -7 Analyze classes – Purpose Identify the responsibilities of analysis classes Identify the attributes and relationships of the analysis classes Capture special requirements on the realization of the class – Steps Identify responsibilities Identify attributes Identify associations and aggregations Identify generations Capture special requirement

Activities of Analysis -8 Analyze classes - 2 – Identify responsibilities Identify all the roles it plays in all use-case realizations (p208, ex) Extract responsibilities from one role at a time (p208, ex) Adding additional or change existing responsibilities based on one use-case realization at a time. – Identify attributes An attribute specifies a property of an analysis class They are implied or required by the responsibility of the class

Activities of Analysis -9 Analyze classes - 3 – Identify associations and aggregations Links in collaboration diagrams may imply the need for references and aggregations among objects The # of relationships between classes should be minimized. (p 209, ex; p210, Fig 8.27)) – Identify generations (p210, Fig 8.28) Extract common and shared behavior among classes Should be at high and conceptual level for better understanding – Capture special requirements Nonfunctional requirements on the analysis class May be inherited from the nonfunctional requirements of the use case realization (p211, ex)

Activities of Analysis -10 Analyze packages – Purpose Ensure analysis packages are independent of each other (loose coupling) Ensure analysis packages fulfill the purpose of realizing domain classes or use cases Describe the dependencies – Guidelines (p212, Fig 8.30) Define the dependencies of the package on other packages whose contained classes are associated with it Make sure the package contains the right classes Limit the dependencies to other packages

Summary of Analysis Artifacts – Analysis packages and service packages – Analysis classes, their responsibilities, attributes, etc – Use-case realizations – Analysis – Architectural view of the analysis model Workflow – Architectural analysis – Analyze use-cases – Analyze classes – Analyze packages