53
Analysis Preeti Mishra Course Instructor

Analysis

Embed Size (px)

Citation preview

Page 1: Analysis

AnalysisAnalysis

Preeti MishraCourse Instructor

Page 2: Analysis

System DevelopmentSystem Development

Page 3: Analysis

Introduction

• System development is model building• Starts when a requirement of system identified• Specification can be used for contract and to plan

andcontrol the development process

• As Complex process handle poorly so any systematic method like structured or OOAM can used from start to end of system life cycle

Page 4: Analysis

Introduction

• Selecting a methodology is not simple, as no one methodology is always best.

• Many organizations have their own standards.• Systems nature, constraints, and rules playing a

major rule in deciding which methodology to use• Your experience as analyst is important to

compare and decide which methodology to use

Page 5: Analysis

Structured Analysis and Design Vs OO Analysis and Design

• Structured analysis is a traditional systems development technique that is time-tested and easy to understand.

• Structured analysis uses a set of process models to describe a system graphically.

• Because it focuses on processes that transform data into information, structured analysis is called a process-centered technique

• Whereas structured analysis treats processes and data as separate components, object-oriented analysis combines data and the processes that act on the data into things called objects.

• System analysts use O-O to model real world business processes and operation.

• The result is a set of software objects that represent actual people, things, transactions and events

Page 6: Analysis

Traditional Software Development

Page 7: Analysis

Structured analysis and design

– Advantages of Structured analysis and design• visual, so it is easier for users/programmers to

understand• Makes good use of graphical tools• A mature technique• Process-oriented approach is a natural way of

thinking• simple and easy to understand and impalement

Page 8: Analysis

Disadvantages of Structured analysis and design

• Not enough user-analyst interaction• It depends on dividing system to sub systems

but it is to decide when to stop decomposing

Page 9: Analysis

Object Orientation

Enca

psul

atio

n

Abs

trac

tion

Hie

rarc

hy

Mod

ular

ity

Basic Principles of Object Orientation

Page 10: Analysis

Basic Concepts of Object Orientation(Few of them Already Studied)

• Object• Class• Attribute• Operation• Interface (Polymorphism)• Component• Package• Subsystem• Relationships

Page 11: Analysis

Systems Development Methodologies

Object-Oriented analysis and design

– Object-Oriented analysis and design becoming popular because of its ability to thoroughly: • represent complex relationships, • as well as represent data and data processing with a

consistent notation– Object-Oriented analysis and design blend

analysis and design in evolutionary process– It allows you to deal with the complexity

inherent in a real-world problem by focusing on the essential and interesting features of an application

Page 12: Analysis

Systems Development Methodologies

Object-Oriented analysis and design

– Process of progressively developing representation of a system component (or object) through the phases of:• analysis, • design and • implementation

– The model is abstract in the early stages– As the model evolves, it becomes more and

more detailed

Page 13: Analysis

Object-Oriented systems development life cycle

• Object-Oriented analysis and design• object representation through three phases

– analysis, – design, and – implementation

Page 14: Analysis
Page 15: Analysis

Analysis, Design, and

Implementation

Analysis, Design, and

Implementation

Page 16: Analysis

Analysis Phase

– Object-oriented analysis is a popular approach that sees a system from the viewpoint of the objects themselves as they function and interact

– Model of the real-world application is developed showing its important properties

– Model specifies the functional behavior of the system independent of implementation details

Page 17: Analysis

Design Phase

– Design Phase• Analysis model is refined and adapted to the

environment• Can be separated into two stages

– System design» Concerned with overall system architecture

– Object design» Implementation details are added to system design

Page 18: Analysis

Implementation Phase

– Implementation Phase• Design is implemented using a programming

language and/ or database management system

Page 19: Analysis

Testing Phase follows..

• Testing Process– Unit– Integration– System

Page 20: Analysis
Page 21: Analysis

Analysis In DetailAnalysis In Detail

Page 22: Analysis

Introduction

• The analysis phase   defines the requirements of the system, independent of how these requirements will be accomplished.

• This phase defines the problem that the customer is trying to solve.

• The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built.

• This analysis represents the ``what'' phase.• The requirement document tries to capture the

requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details.

Page 23: Analysis

Object Oriented Analysis

• We use UML (Unified Modeling Language) to represent the analysis details.

• Following models are used to model the Object Oriented Analysis using UML– Use Case Diagram– Class diagram

Page 24: Analysis
Page 25: Analysis

Domain ModelDomain Model

Page 26: Analysis

What is a domain model?

• “A domain model captures the most important types of objects in the context of the business.

The domain model represents the ‘things’ that exist or events that transpire in the business environment.” – I. Jacobsen

Page 27: Analysis

What is a Domain Model?

• Illustrates meaningful conceptual classes in problem domain

• Represents real-world concepts, not software components

Page 28: Analysis

Why do a domain model?

• Gives a conceptual framework of the things in the problem space

• Helps you think – focus on semantics• Provides a glossary of terms – noun based• It is a static view - meaning it allows us convey time

invariant business rules• Foundation for use case/workflow modelling• Based on the defined structure, we can describe the

state of the problem domain at any time.

Page 29: Analysis

Features of a domain model

• The following features enable us to express time invariant static business rules for a domain:-o Domain classes – each domain class denotes a type of object.  o Attributes – an attribute is the description of a named slot of a

specified type in a domain class; each instance of the class separately holds a value.  

o Associations – an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship.

o Additional rules – complex rules that cannot be shown with symbology can be shown with attached notes.

Page 30: Analysis
Page 31: Analysis

Identifying Domain Classes from Problem

Statement

Identifying Domain Classes from Problem

Statement

Page 32: Analysis

How to Draw Domain Model

• Reuse an existing domain model – There are many published, well-crafted domain

models. • •Use a conceptual class category list

– Make a list of all candidate conceptual classes • •Identify noun phrases

– Identify nouns and phrases in textual descriptions of a domain ( use cases, or other documents)

Page 33: Analysis

Domain classes?

• Each domain class denotes a type of object. It is a descriptor for a set of things that share common features. Classes can be:-o Business objects - represent things that are manipulated in the

business e.g. Order.o Real world objects – things that the business keeps track of

e.g. Contact, Site.o Events that transpire - e.g. sale and payment.

• A domain class has attributes and associations with other classes

• It is important that a domain class is given a good description

Page 34: Analysis

There are different types of Objects

• Entity Objects– Represent the persistent information

tracked by the system (Application domain objects, also called “Business objects”)

• Boundary Objects– Represent the interaction between the user

and the system• Control Objects

– Represent the control tasks performed by the system.

Page 35: Analysis

Year

Month

Day

ChangeDateButton

LCDDisplay

Entity Objects Control Object Boundary Objects

To distinguish different object types in a model we can use the UML Stereotype mechanism

Page 36: Analysis

Class Identification

Class identification is crucial to object-oriented modeling– Helps to identify the important entities of a

system

• Basic assumptions: 1. We can find the classes for a new

software system (Forward Engineering)2. We can identify the classes in an existing

system (Reverse Engineering)

• Why can we do this? – Philosophy, science, experimental

evidence.

Page 37: Analysis

Class Identification

• Approaches– Application domain approach

• Ask application domain experts to identify relevant abstractions

– Syntactic approach• Start with use cases• Analyze the text to identify the objects• Extract participating objects from flow of events

– Design patterns approach• Use reusable design patterns

– Component-based approach • Identify existing solution classes.

Page 38: Analysis

Ways to find Objects • Syntactical investigation with Abbot‘s

technique:– Flow of events in use cases– Problem statement

• Use other knowledge sources:– Application knowledge: End users and experts know

the abstractions of the application domain– Solution knowledge: Abstractions in the solution

domain– General world knowledge: Your generic knowledge and

intution

Page 39: Analysis

Class identification is a Hard Problem

• One problem: Definition of the system boundary:– Which abstractions are outside, which abstractions are

inside the system boundary?• Actors are outside the system• Classes/Objects are inside the system.

• An other problem: Classes/Objects are not just found by taking a picture of a scene or domain– The application domain has to be analyzed– Depending on the purpose of the system different

objects might be found• How can we identify the purpose of a system?• Scenarios and use cases => Functional model

Page 40: Analysis

Steps for Domain Classes

1. Make a list of potential objects by finding out the nouns and noun phrases from narrative problem statement

2. Apply subject matter expertise (or domain knowledge) to identify additional classes

3. Filter out the redundant or irrelevant classes 4. Classify all potential objects based on categories.5. Group the objects based on similar attributes. While grouping we

should remember that Different nouns (or noun phrases) can actually refer to the same thing (examples: house, home, abode)

6. Same nouns (or noun phrases) could refer to different things or concepts (example: I go to school every day / This school of thought agrees with the theory)

7. Give related names to each group to generate the final list of top level classes Iterate over to refine the list of classes

Page 41: Analysis

Listing Noun Phrases

• An obvious way to identify domain classes is to identify nouns and phrases in textual descriptions of a domain.

• Consider a use case description as follows:-1.      Customer arrives at a checkout with goods and/or services to purchase.2.      Cashier starts a new sale.3.      Cashier enters item identifier.4.      System records the sale line item and presents the item

description, price and running total.

Page 42: Analysis

Where to identify conceptual classes from noun phrases

• Vision and Scope, Glossary and Use Cases are good for this type of linguistic analysis

• However: – •Words may be ambiguous or synonymous – •Noun phrases may also be attributes or

parameters rather than classes: • If it stores state information or it has multiple behaviors, then

it’s a class • If it’s just a number or a string, then it’s probably an attribute

Page 43: Analysis

Few Hints..

Categories Explanation

People Humans who carry out some function

Places Areas set aside for people or things

Things Physical objects

OrganizationsCollection of people, resources, facilities and capabilities having a defined mission

Concepts Principles or Ideas not tangible

EventsThings that happen (usually at a given date and time), or as a steps in an ordered sequence

Page 44: Analysis

Identifying attributes ?

• A domain class sounds like an attribute if: -

o It relies on an associated class for it’s identity – e.g. ‘order number’ class associated to an ‘order’ class. The ‘order number’ sounds suspiciously like an attribute of ‘order’.

o It is a simple data type – e.g. ‘order number’ is a simple integer. Now it really sounds like an attribute!

Page 45: Analysis
Page 46: Analysis

Combining the learning

Perform the following in very short iterations: o Make a list of candidate domain classes.o Draw these classes in a UML class diagram.o If possible, add brief descriptions for the classes.o Identify any associations that are necessary.o Decide if some domain classes are really just attributes.o Where helpful, identify role names and multiplicity for

associations.o Add any additional static rules as UML notes that cannot be

conveyed with UML symbols.o Group diagrams/domain classes by category into packages.

Concentrate more on just identifying domain classes in early iterations !

Page 47: Analysis

Steps in Generating Class Diagrams

1. Class identification (textual analysis, domain expert)

2. Identification of attributes and operations (sometimes before the classes are found!)

3. Identification of associations between classes4. Identification of multiplicities5. Identification of roles6. Identification of inheritance

Page 48: Analysis

Work it out…

• example

Page 49: Analysis

Who uses Class Diagrams?

• Purpose of class diagrams– The description of the static properties of a

system• The main users of class diagrams:

– The application domain expert• uses class diagrams to model the application

domain (including taxonomies)– during requirements elicitation and analysis

– The developer • uses class diagrams during the development of

a system– during analysis, system design, object design and

implementation.

Page 50: Analysis

Who does not use Class Diagrams?

• The client and the end user are usually not interested in class diagrams – Clients focus more on project management

issues – End users are more interested in the

functionality of the system.

Page 51: Analysis

Developers have different Views on Class Diagrams

• According to the development activity, a developer plays different roles:– Analyst– System Designer– Object Designer– Implementor

• Each of these roles has a different view about the class diagram (the object model).

Page 52: Analysis
Page 53: Analysis

An overview of OOSE development activities and their products

Requirementselicitation

Analysis

System design

problem statement

functionalmodel

nonfunctionalrequirements

analysis object model dynamic

model

class diagram

use case diagram

statechart diagram

sequence diagram