Analysis

AnalysisAnalysis

Preeti MishraCourse Instructor

System DevelopmentSystem Development

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

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

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

Traditional Software Development

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

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

Object Orientation

Enca

psul

atio

n

Abs

trac

tion

Hie

rarc

hy

Mod

ular

ity

Basic Principles of Object Orientation

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

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

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

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

Object-Oriented systems development life cycle

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

– analysis, – design, and – implementation

Analysis, Design, and

Implementation

Analysis, Design, and

Implementation

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

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

Implementation Phase

– Implementation Phase• Design is implemented using a programming

language and/ or database management system

Testing Phase follows..

• Testing Process– Unit– Integration– System

Analysis In DetailAnalysis In Detail

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.

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

Domain ModelDomain Model

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

What is a Domain Model?

• Illustrates meaningful conceptual classes in problem domain

• Represents real-world concepts, not software components

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.

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.

Identifying Domain Classes from Problem

Statement

Identifying Domain Classes from Problem

Statement

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)

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

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.

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

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.

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.

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

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

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

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.

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

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

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!

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 !

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

Work it out…

• example

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.

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.

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).

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