1. Analysis Modelling Approaches - Structured Analysis Considers data and the process that transforms the data into separate entities –Data objects Modelled in a way that defines their attributes and relationships –Processes (that manipulate data objects) Modelled in a manner that shows how they transform data as data objects flow through the system

2. Analysis Modelling Approaches - Object-Oriented Analysis Focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements

3. Data Modelling Concepts Requirements analyst defines: –All data objects that are processed within the system –Relationships between data objects –Other information that is pertinent to the relationships

4. Data Modelling Concepts Data object –A representation of almost any composite information that must be understood by software Composite information – something that has a number of different properties/attributes e.g. “width” is not a valid data object “dimensions” is a valid data object as it incorporates height, width and depth –Encapsulates data only, there is no reference within a data object to operations that act on the data Data object description –Incorporates data object and all of its attributes

5. Examples of data objects –External entity – anything that produces/consumes information –Thing – report or display –Occurrence – a telephone call –Event – an alarm –Role – salesperson –Organisational unit – accounting department –Place – a warehouse –Structure – a file

6. Data Attributes Define properties of a data object, which can take one of three different characteristics: –Name of an instance of data object –Describing the instance –Making reference to another instance in another table The set of attributes that is appropriate for a given data object is determined through an understanding of the problem statement

7. Relationships Indicate that objects are connected to one another Arrows provide important information about directionality of the relationship –This often reduces ambiguity or misrepresentations personcar owns insured to drive

8. Cardinality and Modality Elements of data modelling – data object, attributes and relationships – provide the basis for understanding the information domain of a problem Additional information related to these basic elements must be understood –Cardinality –Modality

9. Cardinality Concept that states how many of occurrences of object X are related to how many occurrences of object Y –Represent the number of occurrences of objects in a given relationship –Also defines the maximum number of objects that can participate in a relationship

10. Modality Provides and indication whether or not a particular data object must participate in the relationship –If there is no explicit need for the relationship to occur or the relationship is optional Modality is 0 –If an occurrence of the relationship is mandatory Modality is 1

11. Object-Oriented Analysis Defines all classes (and the relationships and behaviour associated with them) that are relevant to the problem to be solved To accomplish this a number of tasks must occur: 1.Basic user requirements must be communicated between the customer and the developer 2.Classes must be identified (i.e. attributes and methods are defined) 3.Classes hierarchy is defined 4.Object-to-object relationships (object connections) should be represented 5.Object behaviour must be modelled 6.Tasks 1 through 5 are reapplied until the model is complete

12. Object-Oriented Analysis Builds a class-oriented model that relies on an understanding of OO concepts OO concepts encountered during analysis modelling –Attributes –Class –Objects –Operations –Subclass –Superclass

13. OO concepts(analysis modelling) Attributes –A collection of data values that describes a class Class –Encapsulates that data and procedural abstractions required to describe the content and behaviour of some real world entity. –Generalised description that describes a collection of similar objects Objects –Instances of a specific class –Inherit classes’ attributes and operations

14. OO concepts(analysis modelling) Operations –Also called methods and services, provide a representation of one of the behaviours of a class Subclass –A specialisation of the superclass –Can inherit both attributes and operations from a superclass Superclass –Also called a base class –Is a generalisation of a set of classes that are related to it

15. Elements in a model Scenario-based elements Class-based elements Behavioural elements Flow-oriented elements

16. Scenario-based Modelling If software engineers understand how end-users (and other actors) want to interact with the system, the development team will be better able to properly characterise requirements and build meaningful analysis and design models Analysis modelling with UML begins with creation of scenarios in the form of use-cases and activity diagrams

17. Writing use-cases Captures the interactions that occur between producers and consumers of information and system itself Describe a specific usage scenario in a straightforward language from the viewpoint of a defined actor –Actor is anything/anyone that communicates with the system/product and that is external to the system Elicitation provides us with enough information to begin writing use-cases

18. Writing use-cases Begin with listing the functions or activities performed by a specific actor –May be obtained from a list of required system functions, –through conversations with customers/end-users, or –By an evaluation of activity diagrams In general, use-cases are written first in an informal narrative fashion –A sequential presentation of a use-case scenario, which does not consider any alternative interactions, are referred to as primary scenarios. –A description of alternative interactions are essential to a complete understanding of the function that is being described

19. Writing use-cases Each step in primary scenario is evaluated by asking the following questions: –Can the actor take some other action at this point? –Is it possible that the actor will encounter some error condition at this point? If so, what might it be? –Is it impossible that the actor will encounter some other behaviour at this point? e.g. behaviour that is invoked by some event outside the actor’s control If so, what might it be? Answers to these questions result in the creation of a set of secondary scenarios that are part of the original use-case but represent alternative behaviour

20. Writing use-cases There is no need to create a graphical representation of a usage scenario However,diagrammatic representation can facilitate understanding particularly when the scenario is complex

21. Developing an Activity Diagram Activity diagram supplements the use-case by providing a graphical representation of the flow of the interaction within a specific scenario Similar to a flowchart: –Rounded rectangle imply a specific system function –Arrows represent flow through the system –Decision diamonds depict a branching decision, where each arrow emanating from the diamond is labelled –Solid horizontal lines indicate parallel activities are occurring

22. Flow-oriented Modelling Data flow modelling is a core modelling activity in structured analysis Data Flow Diagram (DFD) takes an input-process- output view of the system, i.e. –data objects flow into the software –data objects are transformed by processing elements –resultant data objects flow out of the software Data objects are represented by labelled arrows Transformations are represented by circles (bubbles)

23. Data Flow Diagram Represented in a hierarchical fashion First dataflow model represents the system as a whole –Level 0 DFD or context diagram Subsequent data flow diagrams refine the context diagram, providing increasing detail with each subsequent level Enables developers to develop models of information domain and functional domain at the same time

24. DFD Systems analyst performs an implicit functional decomposition of the system, as DFD is refined into greater detail Also, DFD results in a corresponding refinement of data as it moves through the processes that embody the application

25. Creating a DFD Level 0 DFD should depict software/system as a single bubble Primary input and output should be carefully noted Refinement should begin by isolating candidate process, data objects, and data stores to be represented at the next level All arrows and bubbles should be labelled with meaningful names

26. Creating a DFD Information flow continuity must be maintained from level to level –i.e. data objects that flow into the system or any transformation at one level must be the same data objects (or their constituent parts) that flow into the transformation at a more refined level. One bubble at a time should be refined Overcomplication caused by attempts to show too much detail too early or represents procedural aspects of the software instead of informational flow

27. Levels in DFD Level 0 DFD –Primary external entities (boxes) produce information for use by the system and consume information generated by the system –Labelled arrows represent data objects or data object hierarchies Level 1 DFD –Expands from level 0 DFD using an effective approach of “grammatical parse” on the first set of requirements (narrative) that describe the context bubble. –“grammatical parse” isolates nouns(noun phrases) and verbs(verb phrases) –Verbs are processes and may be represented by bubbles in a subsequent DFD –Nouns are either external entities (boxes), data or control object(arrows), or data stores (double lines)

28. Considerations in creating DFD Nouns and verbs may be associated with one another –In the case of nouns, these can be attributes Refinement of DFDs continues until each bubble performs a simple function –i.e. until the process represented by the bubble performs a function that would be easily implemented as a program component

29. Control Flow Model Applications can be “driven” by events rather than data, produce control information rather than reports or displays, and process information with heavy concern for time and performance –Such application requires the use of control flow modelling in addition to data flow modelling Event or control item is implemented as: –Boolean value (True/False, On/Off, 1/0) –Discrete list of conditions (empty, jammed, full)

30. Control Flow Model Guidelines to select potential candidate events: –List all sensors that are “read” by the software –List all interrupt conditions –List all “switches” that are actuated by an operator –List all data conditions –“grammatical” parse is applied to processing narrative and all “control items” are review as possible control flow inputs/outputs –Describe behaviour of a system by identifying its states, identifying how each state is reached; and define the transitions between states –Focus on possible omissions For example, ask: “Is there any other way I can get to this state or exit from it”

31. State Diagram A sequential specification of behaviour UML state diagram format is superior in information content and representation, that state transition diagram for structured analysis Indicates how the system responds to events as it traverses the states (defined at a level) By reviewing, the behaviour of the system can be determined, and more importantly, it is ascertained whether there are any “holes” in the specified behaviour

32. All flow model processes can that appear at the final level of refinement Content of this specification can include: –A narrative text –Program Design Level (PDL), at design level detail, description of algorithm –Mathematical equations –Tables –Diagrams –Charts

33. Class-based Modelling Class-based elements of an analysis model are: –Classes and objects –Attributes –Operations –Packages –CRC models –Collaboration diagrams

34. Identifying Analysis Classes Begin by examining the problem statement or performing a “grammatical parse” on the use- cases or processing narratives developed for the system to be built Classes determined by underlying each noun (noun clause) and entering it into a simple table –Synonyms should be noted If class is required to implement a solution, then it is part of the solution space Otherwise, if a class is only necessary to describe a solution, it is part of the problem space

35. Analysis Classes External entities (e.g. other systems, devices or people) that produce or consume information to be used by a computer-based system Things (e.g. reports, displays, letters, signals) that are part of the information domain for the problem Occurrences or events (e.g. property transfer or completion of a series of robot movements) that occur within the context of system operation Roles (e.g. manager, engineer, salesperson) played by people who interact with the system Organisational units (e,g, division, group, team) that are relevant to an application

36. Analysis Classes Places (e.g manufacturing floor or loading dock) that establish the context of the problem and overall function of the system Structures (e.g. sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects

37. Selection Criteria for Analysis Classes Retained information –Potential class is useful during analysis, if only information about it must be remembered so that the system can function Needed services –Potential class must have a set of identifiable operations that can change the value of its attributes in some way Multiple attributes –In requirements analysis, focus should be on “major” information –So a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity

38. Selection Criteria for Analysis Classes Common attributes –Set of attributes can be defined for the potential class and these attributes apply to all instance of the class Common operations –Set of operations can be defined for the potential class, and these operations apply to all instances of the class Essential requirements –External entities that appear in the problem space and produce or consume information essential to the operation of the solution for the system will almost always be defined as classes in the requirements model

39. Specifying Attributes Attributes describe a class and clarify what is meant by the class in the context of the problem To develop a meaningful set of attributes for an analysis class –Study a use-case and those things that reasonably “belong” to the class –Also, ask: “What data items (composite and/or elementary) fully define this class in the context of the problem?”

40. Define Operations Define the behaviour of an object Broad categories of operations: –Operations that manipulate data in some way (e.g. adding, deleting, reformatting, selecting) –Operations that perform a computation –Operations that inquire about the state of an object –Operations that monitor an object for the occurrence of a controlling event In the first iteration of deriving a set of operations for an analysis class, study a use-case and select those operations that reasonably belong to the class –“grammatically parse” to select verbs –Some of these verbs are legitimate operations and can be easily connected to the class

41. Class-Responsibility- Collaborator Modelling Provide a simple means for identifying and organising the classes that are relevant to system or product requirements Intent is to develop an organised representation of classes Responsibilities are attributes and operations that are relevant to the class –i.e. “anything that the class knows or does” Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility –In general, it implies either a request for information or some action

42. Other Categories of Classes Entity class (model or business class) –Extracted directly from the problem statement –Typically represents things that are to be stored in a database and persist throughout the duration of the application (unless they are specifically deleted) Boundary class –Used to create the interface(e.g. interactive screen or printed reports) that the user sees and interacts with as the software is used –Designed with the responsibility of managing the way entity objects are represented to the users

43. Other Categories of Classes Controller class –Manage a “unit of work” from start to finish –Can be designed to manage: Creation or update of entity objects Instantiation of boundary objects, as they obtain information from entity objects Complex communication between sets of objects Validation of data communicated between objects or between user and application –In general, it is note considered until design has begun

44. Guidelines for Identifying Responsibilities 1.System intelligence should be distributed across all classes to best address the needs of the problem Every application encompasses a certain degree of intelligence, i.e. what the system knows and what it can do One which promotes high cohesion and enhances the maintainability of the software and reduces the impact of side effects due to change is even distribution of intelligence. i.e. each object knows about and does only a few things (that are generally well-focused) Responsibilities should exhibit some level of abstraction for each class

45. Guidelines for Identifying Responsibilities 2.Each responsibility should be stated as generally as possible Implies that general responsibilities should reside high in the class hierarchy (because they are generic, they will apply to all subclasses) 3.Information and the behaviour related to it, should reside within the same class Achieves the OO principle of encapsulation Data processes that manipulate data should be packaged as a cohesive unit

46. Guidelines for Identifying Responsibilities 4.Information about one thing should be localised with a single class, not distributed across multiple classes Single class should take on the responsibility for storing and manipulating a specific type of information Responsibility should not, in general, be shared across a number of classes If information is distributed, software becomes more difficult to maintain and more challenging to test

47. Guidelines for Identifying Responsibilities 5.Responsibilities should be shared among related classes, when appropriate There are cases in which a variety of related objects must all exhibit the same behaviour at the same time Collaborate with other objects to perform the responsibility

48. Collaborations Classes fulfil their responsibilities in one of two ways: –Class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility –Class can collaborate with other classes Collaborations identify relationships between classes Collaborations are identified by determining whether a class can fulfil each requirement itself –if it cannot, it needs to interact with another class

49. Identifying collaborators Examine three generic relationships between classes: –is-part-of All classes that are part of an aggregate class are connected to the aggregate class –has-knowledge-of one class must acquire information from another class –depends-upon Implies that two classes have a dependency that is not achieved by has-knowledge-of or is-part-of dependency

50. Associations and Dependencies Associations describe the relationship when two analysis classes are related to one another –May further be defined by indicating multiplicity (cardinality) –e.g. in UML, one or more  1..*, 0 or more  0..* Dependency describes the relationship when a client-server relationship exist –Client-class depends on a server-class –Defined as a stereotype, an “extensibility mechanism” within UML that allows a software engineer to define a special modelling element, whose semantics are custom-defined Represented by double angle brackets  >

51. Analysis Packages Important part of an analysis modelling is categorisation Various elements of analysis model (e.g. use-case, analysis classes) are categorised in a manner that packages them in a grouping –an analysis package

52. Behavioural Model Behaviour of the system must be represented as a function of the specified events and time Behaviour model indicates how software will respond to external events or stimuli

53. Creating a Behavioural Model Evaluate all use-cases to fully understand the sequence of interaction within the system Identifying events that drive the interaction sequence and understand how these events relate to specific classes Create a sequence for each use-case Build a state diagram for the system Review the behavioural model to verify accuracy and consistency

54. Identifying events with Use-Case Use-case represents a sequence of activities that involves actors and the system –In general, an event occurs whenever the system and an actor exchange information –Event is not the information that has been exchanged, but rather the fact that information has been exchanged Use-case is examined for points of information exchange –An actor should be identified for each event –Information that is exchanged should be noted –Any conditions or constraints should be listed Once all events are identified, they are allocated to the objects involved

55. State Representations In the context of behavioural modelling, two characteristics of states must be considered: –State of each class as the system performs its function –State of the system, as observed from the outside, as the system performs its functions State of class takes on both passive and active characteristics –Passive state  simply the current status of all an object’s attributes –Active state  indicates the current status of the object as it undergoes a continuing transformation or processing Event (trigger) must occur to force an object to make a transition from one active state to another

56. Behavioural Representations State diagrams for analysis classes –Discusses how individual classes change state based on external events Sequence diagrams –Shows the behaviour of software as a function of time

57. State Diagrams for Analysis Classes Represent active states for each class and the events (triggers) that cause changes between active states –Arrow represents a transition from one active state of a class to another –Labels on arrows represent the event that triggers the transition Can also specify a guard and an action –A guard is a Boolean condition that must be satisfied in order for transition to occur In general, it depends on the passive state (value of one or more attributes) of the object –An action occurs concurrently with a state transition or as a consequence of it generally involves one/more operations (responsibilities) of the object

58. Sequence Diagrams Indicates how events cause transitions from object to object A representation of how events cause flow from one object to another as a function of time Represents key classes and events that cause behaviour to flow from class to class Arrows represent an event (derived from use-case) and indicates how events channels behaviour between objects

59. Sequence Diagrams Time is measured vertically downwards Narrow vertical rectangles represent the time spent in processing an activity States may be shown along a vertical line Once complete sequence diagram is developed, all of the events that cause transitions between system objects can be collected into a set of input events and output events (from an object) –This is useful in creating an effective design for the system to be built