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

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

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

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

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

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

Relationships

• Indicate that objects are connected to one another

• Arrows provide important information about directionality of the relationship– This often reduces ambiguity or

misrepresentations

person car

owns

insured to drive

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

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

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

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 developer2. Classes must be identified (i.e. attributes and methods are defined)3. Classes hierarchy is defined4. Object-to-object relationships (object connections) should be

represented5. Object behaviour must be modelled6. Tasks 1 through 5 are reapplied until the model is complete

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

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

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

Elements in a model

• Scenario-based elements

• Class-based elements

• Behavioural elements

• Flow-oriented elements

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

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

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

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 controlIf 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

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

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

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)

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

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

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

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

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)

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

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)

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”

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

• 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

Class-based Modelling

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

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

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

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

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

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

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?”

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

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

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

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

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

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

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

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

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

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

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 <<stereotype>>

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

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

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

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

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

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

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

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

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