Why Analysis Process Refer to earlier chapters Models what the system will do makes it easier for understanding no environment considered (hence, system architecture focuses only on the problem) can discuss model with user in their terms

Results of analysis process Fig 7.1 Requirements model helps delimits the system and defines the functionality Fig 7.2 Example system

The requirements model Consists of use cases, problem domain object model, and user interface descriptions It is structured by the analysis model, realized by the design model, implemented by the implementation model and tested by the testing model. All models are tested against the requirements mode and are derived from it.

Actors anything external to the system first define boundary (system delimitation) Fig 7.3 Primary actor (direct beneficiary) Secondary actor (actors supervising and maintaining the system) Difficult to identify non human actors (until use cases are written down)

Use cases A specific way of using a system by performing some part of the functionality It consists of a complete course of events initiated by an actor and specifies his interaction with the system Actors help in defining use cases Use cases are instantiated every time a user performs a use case To identify use cases, ask the following questions –what are the main tasks for each user –will the actor read/write/change any of the system information –will the actor have to inform the system about outside changes –does the actor wish to be informed about unexpected changes –Fig 7.4 (+ use case description in page 161)… a first cut at use cases for the recycling system

Cont. It is not obvious what functionality should be placed in separate use cases and what is only a variant of one and the same use case Description of the most important course of events lead to Basic Course variants of Basic Course lead to alternative course (exception processing etc.) Extension specifies how one use case description may be inserted into, and thus extend, another use case description (Fig ) (use case description page 164) When to use Extensions –to model optional parts of a use case –to model complex and alternative courses which seldom occur, for instance Item Stuck in our example –to model separate sub-courses which are executed only in certain cases –to model situation where several different use cases can be inserted into special case, such as login/logout in fig 7.6 After Extension is completed, the normal course of events proceed as usual

Interface description For man machine interface - sketch what the user sees on screen for performing a use case If interface are hardware protocols, refer to various standards maintain consistency between user’s conceptual picture and the systems actual behavior The recycling machine has a set of interface for the customer and one set for the operator

Problem domain objects define objects (noun list) helps in defining actors and use cases in the requirements model since users and orders recognize all objects in this model, it is a good start for defining the system helps in developing a more robust analysis model that is maintainable Refining problem domain objects (fig 7.7) many of the domain objects show up as entity objects in the analysis model(do not do a one to one mapping) problem domain model example (Fig 7.8) Can use this for enterprise modeling too

Further refinements to requirements model Required for a transition to analysis model abstract use cases - parts common to many use cases, abstract use case can inherit from other abstract use cases too. Stop inheritance, once the operations are on objects concrete use cases - what is actually instantiated instead of inheritance we call it uses (fig ) Choice between extension and uses –depends on how strongly coupled the use cases are –for strongly coupled cases where insertion must occur - use uses –uses are found through extraction of common sequences in many cases –extensions are for specific cases and are used when new courses are introduced in a case

Deciding on length of a use case Benefits of having sequence as one complete use case are –we follow complete flow through the system –from the orderer’s point of view, it is logical cohesive flow of events in the system –it may be more effective while testing the use cases since it covers most logical events in the system –it is easier t synchronize the use case since it is one sequence that starts different events in chronological order Benefits of separating the use case into different use cases –It may be troublesome to find the right instance of a use case that is of large extent since the use case may very well last several days –from a potential actors view, it is more logical to have use cases that a actor starts –it may be easier to test a use case, since every use case starts from external event and not from internal system events

Analysis model Starts after the requirements model has been signed off by the orderers describe the system using three types of objects (fig 7.12) Aim is to create a good platform for system design 7.13 maps objects to use cases (note that the objects can be common to many use cases) after identifying the objects, write down their role in detail

Interface objects They describe bi-directional communication between system and it users (fig 7.14) Ways to identify interface objects –systems interface description in the requirements –start from the actors –read the use case descriptions and extract functionality that is interface-specific (see use case description in page 176) Static associations between instances - acquaintance associations help in communication between interface objects (Fig 7.15) Special case of acquaintance association is consists of (or aggregate ) association (7.18 Two type of interface to model –to communicate with users (User Interface Management systems) –to communicate with other systems (know the protocol)

Cont Four strategies to allocate functionality to interface objects for sequencing operations –Computation dominant control or embedded control - interface objects do not have much functionality –Dialogue dominant control - a lot of functionality in the interface object –Mixed control - places control on both sides allowing invocation of a dialogue from the computational side and vice versa. This increases flexibility but programmers should strive to maintain dialogue independence –Balanced control - we separate control from both the dialogue and the computation. The global control component, the control object, governs sequencing among invocation of dialogue and computational functions.

Entity Objects To model information that the system will handle over a longer period of time we use entity objects often identified in the problem domain object model Use case description in p.g. 185 leads to three entity objects, cans, bottles, and crates the three are can inherit common properties from Deposit item (fig 7.19) info about each object are stored as their attributes (7.20, 7.21) (and extracted from the use case descriptions) The entity object ‘Receipt Basis’ is required to keep info about each customer’s returns for end of day job. This object has a acquaintance association with deposit item in order to function properly (Fig. 7.22)

How to decide between an attribute and object –if the info is used separately - model it as an object –if it is strongly coupled to some other information and never used alone model it as an attribute of an entity –same info can be viewed differently under different circumstances postpone the identification of operations on entity object till construction phase Typical operations in a entity object –storing and fetching information –behavior that must be changed if the entity object is changed –creating and removing entity objects entity objects may have communication associations to pass information

Control objects what is a control object? Aim should be to tie only one actor to one control object Control objects tie together courses of events and thus carry on communication with other objects Case description in Page 192 identifies some control objects (one per use case -- Fig 7.24) 7.25 show how alarm is injected into deposit item receiver object

Working with analysis objects We normally identify all objects for one use case and then proceed to the next use case however, one object may participate in more than one use case, this process is iterative describe each objects role and responsibilities when describing behavior, concentrate on ‘what’ not ‘how’ Fig 7.26 (+ use case description in page 194-5) gives the use case view of objects showing how they will be used in a use case. It shows the model of reality, (that is relevant to the system)

Subsystems for large systems, objects can be grouped as subsystems the lowest level of subsystem can be viewed as a change unit (or service packages) subsystems can be formed based on coupling of objects The following criteria can be used to determine whether objects are functionally related –will changes in one object lead to changes in the other object –do they communicate with the same actor –are both dependent on a third object –does one object perform several operations on the other Fig example of a subsystem