Systems Developmenty p

Dr Wachara ChantatubDr. Wachara ChantatubFaculty of Commerce and Accountancy

Chulalongkorn UniversityChulalongkorn UniversityEmail: wachara@acc.chula.ac.th

Systems DevelopmentSystems Development

Systems Development ProcessSystems Development Life Cycle (SDLC) ModelPeople Involved in Systems DevelopmentCost of the SDLCC t f ECost of ErrorsWhat Makes a System Unsuccessful?What Makes a System Successful?What Makes a System Successful?Structured System Analysis and DesignObject-Oriented Analysis and DesignObject Oriented Analysis and Design

Systems Development ProcessSystems Development Process

In a broad sense, the systems development process entails the translation of requirements into a working system which meets such requirements.In order to make the systems development process more manageable and more visible, p gthe concept of the systems development life cycle model (SDLC) has come into y ( )prominence.

Systems Development Life Cycle (SDLC) Model

Th lif l f t b i h th The life cycle of a system begins when the need for the system is identified and ends

h it i l dwhen it is no longer used.The purpose of a SDLC model is to improve

d ti it ti li d ft litproductivity, timeliness, and software quality.The SDLC model should:

describe the phases of the development processdescribe the phases of the development processgive guidelines for how to carry out the phasesprovide methodologies that are predictable and provide methodologies that are predictable and repeatable.

A SDLC model helps developers and p pmanagement acquire insight into the systems development process.

A number of different SDLC models have been proposed. Some of the well known models are:

1) W t f ll M d l d It ti W t f ll M d l1) Waterfall Model and Iterative Waterfall Model2) Prototyping Model3) I t l M d l3) Incremental Model4) Rapid Application Development (RAD) model) S l d l5) Spiral Model

6) Component-Based Development Model7) Unified Process8) eXtreme Programming (XP)9) Scrum10)Automated Software Synthesis Model

Waterfall Model and Iterative W t f ll M d lWaterfall Model

The first SDLC model proposed was the waterfall model by Dr. Winston W. Royce in 1970.The waterfall model is a sequential software qdevelopment process, in which progress is seen as flowing steadily downwards (like a g y (waterfall) through the phases of System Requirements, Software Requirements, Analysis, Program Design, Coding, Testing, and Operation.

Waterfall Model

Advantages:Advantages:Organized approach, provides robust separation of phases.Reflects common engineering practice.A schedule can be set with deadlines for each stage of development and a product can proceed through the development process, and theoretically, be delivered on time.

Di dDisadvantages:Inflexible partitioning of the project into distinct stages and each phase of development proceeds in strict order, without

l i it ti t k it diffi lt t d any overlapping or iterative steps makes it difficult to respond to changing customer requirements.Only appropriate when the requirements are well-understood. D l t t i ht it f h thDevelopment teams might wait for each other.A working version of the product is available only late.

Iterative Waterfall Model

P t t i M d lPrototyping ModelThis model adds prototyping as sub-process.A prototype is a partially developed product that

bl t d d l t i enables customers and developers to examine some aspect of a proposed system and decide if it is suitable for a finished productsuitable for a finished product.Why add prototypes to the life cycle?

Used to explore the risky aspects of the system.Used to explore the risky aspects of the system.Risk of developing the “wrong” system (what customer doesn’t want), can be a user interface without functionality.

Prototype may be thrown away or evolve into product.

Prototyping Model

Ad tAdvantages:Users get a feel for the actual system.Improve users involvement, communication, clarifications of Improve users involvement, communication, clarifications of requirements and completion of requirementsReduce needs for documentation and maintenance costsProduction of expected resultsProduction of expected results

Disadvantages:The developer may make implementation compromises in p y p porder to get a prototype working quickly.The process is not visible (few documents that reflect every version of the system).version of the system).Systems are poorly structured.Users can misunderstood the role of prototyping

I t l M d lIncremental ModelRather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the increments with each increment delivering part of the required functionality.User requirements are prioritised and the highest User requirements are prioritised and the highest priority requirements are included in early increments.Once the development of an increment is started, the requirements are frozen though requirements for later i t ti t lincrements can continue to evolve.

Incremental Model

Advantages:Funds can be allocated in parts.Customer value can be delivered with each increment so Customer value can be delivered with each increment so system functionality is available earlier.Early increments act as a prototype to help elicit requirements for later increments.Improve knowledge and “lessons learned”.Lower risk of overall project failureLower risk of overall project failure.Small pieces are more manageable, can utilize smaller staff, increase project momentumThe highest priority system services tend to receive the most testing.

Disadvantages:No iterations, difficult to change requirements of prior phasesRequires good planning and users cooperationRequires good planning and users cooperationNot fully defined requirements can be uncomfortable to managementCosts can increase if the physical and the functional design are not fully structuredIncrements need be relatively smallIncrements need be relatively smallMapping requirements to increments may not be easyCommon software facilities may be difficult to identify y y

Rapid Application Development (RAD) M d lModel

Is a team-based technique that speeds up information systems development.R li h il t t i d i l tRelies heavily on prototyping and user involvementTo cut development time and expense by involving the users in every phase of systems developmentthe users in every phase of systems developmentSuccessful RAD team must have IT resources, skills, and management supportand management supportHelps a development team design a system that requires a highly interactive or complex user interfacerequires a highly interactive or complex user interface

RAD Phases and Activities

Rapid Application Development Model

Advantages:Systems can be developed more quickly with significant cost savings

Disadvantages:RAD stresses the mechanics of the system itself and does not emphasize the company’s strategic b i dbusiness needsMight allow less time to develop quality, consistency and design standardsconsistency, and design standards

S i l M d lSpiral Model

Defined by Barry Boehm in his 1988 article “A Spiral Model of Software Development and Enhancement”.Process is represented as a spiral rather than p pas a sequence of activities with backtracking.Each loop in the spiral represents a phase in Each loop in the spiral represents a phase in the process. Suitable for large expensive and complicated Suitable for large, expensive and complicated projects

Riskanalysis

Risk

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Riskanalysis

Riskanalysis

Prototype 2

Prototype 3Opera-tionalprotoype

Riskanalysis Proto-

type 1

Prototype 2 protoype

Concept ofOperation

Simulations, models, benchmarksRequirements planLife-cycle plan

REVIEW

Operation S/Wrequirements

Requirementvalidation

Productdesign Detailed

design

CodeDevelopment

plan

DesignV&V

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Plan next phase

Integrationand test plan

Spiral Model

next-level product

Advantages:Risks are explicitly assessed and resolved throughout the processprocess.Software engineers can start working on the project earlier rather than wading through a lengthy early design process.

Disadvantages:Requires highly skilled people in risk analysis and planningR i i d i iRequires more time, and is more expensive.Estimates of budget and time are harder to judge at the beginning of the project since the requirements evolve beg g o t e p oject s ce t e equ e e ts e o ethrough the process.

Component-based Development M d lModel

Makes intensive use of existing reusable componentsThe focus is on integrating the components rather than on creating them from the scratchgThis approach is becoming increasingly used as component standards have emerged.p g

Requirementsspecification

Componentanalysis

System designwith reuse

Requirementsmodification

Developmentand integration

Systemvalidationvalidation

Component-based Development Model

Ad tAdvantages:Application development improved significantly if applications assembled quickly from prefabricated applications assembled quickly from prefabricated software componentsLess development effort, faster, increase flexibilityLess development effort, faster, increase flexibilityIn principle, more reliable systems, due to using previously tested componentsReduce costs and risks

Disadvantages:Compromises in requirements are neededLess control over the system’s evolution

U ifi d P (UP)Unified Process (UP)

Object-oriented development approachOffered by IBM / Rational y

Booch, Rumbaugh, Jacobson

Unified Modeling Language (UML) used Unified Modeling Language (UML) used primarily for modeling

Unified Process Model

Xt P i (XP)eXtreme Programming (XP)An adaptive, agile development methodology created in the mid-1990s.Sh t l i t l d l t hShort cycles, incremental development approachAutomated tests written by programmers and customerscustomersKey emphases:

Two-person programming teamsTwo-person programming teamsHaving customer on-site during the development processCoding and testing operate togetherg g p g

XP C V lXP Core ValuesCommunication

In open, frequent verbal discussions Simplicity

In designing and implementing solutions Feedback

On functionality, requirements, designs, and codeCourage

In facing choices such as throwing away bad code or standing up to a too-tight schedule

S SP tiSome SP practices:Planning

U d l t f t i t d ib h t th t Users develop a set of stories to describe what the system needs to do

TestingTestingTests are written before solutions are implemented

Pair programmingp g gTwo programmers work together on designing, coding, and testing

Simple designsSimple designs“KISS” and design continuously

R f t iRefactoringImproving code without changing what it does

O i h d ll i lOwning the code collectivelyAnyone can modify any piece of code

Continuous integrationSmall pieces of code are integrated into the system daily or more oftendaily or more often

System metaphorG ides membe s to a ds a ision of the s stemGuides members towards a vision of the system

O it tOn-site customerIntensive user/customer interaction required

S ll lSmall releasesProduce small and frequent releases to user/customeruser/customer

Forty-hour work weekProject should be managed to avoid burnoutProject should be managed to avoid burnout

Coding standardsFollo coding standa ds to ens e fle ibilitFollow coding standards to ensure flexibility

Extreme Programming

SScrumA quick, adaptive, and self-organizing development methodology

Named after rugby’s system for getting an out-of-play ball into playout-of-play ball into play

Responds to a current situation as rapidly and p p ypositively as possible

A truly empirical process control approach to A truly empirical process control approach to developing software

Scrum PhilosophyResponsive to a highly changing, dynamic p g y g g, yenvironmentFocuses primarily on the team levelFocuses primarily on the team level

Team exerts total control over its own organization and work processesp

Uses a product backlog as the basic control mechanismmechanism

Prioritized list of user requirements used to choose work to be done during a Scrum projectwork to be done during a Scrum project

Scrum OrganizationProduct ownerProduct owner

The client stakeholder for whom a system is being builtMaintains the product backlog list

Scrum masterPerson in charge of a Scrum project

Scrum team or teamsSmall group of developers Set their own goals and distribute work among g gthemselves

S P tiScrum PracticesSprint

The basic work process in ScrumA time-controlled mini-projectFi 30 d i b i h ifi l Firm 30-day time box with a specific goal or deliverable

Parts of a sprintParts of a sprintBegins with a one-day planning sessionA short daily Scrum meeting to report progressA short daily Scrum meeting to report progressEnds with a final half-day review

Scrum

Advantages:Advantages:Scrum works very well for a project in which design decisions change often because of the flexibility of the g ydesign approach. Scrum also works well as an IKIWISI ((I Know It When I See It)) approach because the customer is When I See It)) approach because the customer is highly involved and the Scrum process focuses on many iterations which gives the customer an idea upfront of what the design will look like upfront of what the design will look like.

Disadvantages:It would not work well for large teams and projects. g p jWhile it wouldn’t be impossible to do Scrum with a large team and project, Scrum seems to work best with a smaller team.

A t t d S ft S th i M d lAutomated Software Synthesis Model

The process to apply when a mathematical specification is to be developedAutomated transformation of formal requirements into operational codeq pRelies heavily on automated tools (very smart compilers)compilers)

i dRequirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

T1 T2 T3 T4Formal transformations

R2Formal R3 ExecutableR1 R2specification R3 programR1

P2 P3 P4P1

Proofs of transformation correctness

Formal Systems Development

People Involved in Systems D l t Development

Cost of the SDLCCost of the SDLC

Percent of Development activities Total cost_________________________________________Feasibility Study 5Requirements Analysis 25Requirements Analysis 25Design 15Implementation 15Test 13Documentation 12In t ll tion 15Installation 15_________________________________________

100100

Cost of ErrorsCost of Errors

% of Total Cost

E t % f T t l E f EError type % of Total Errors of Errors_____________________________________________R i tRequirementsand Design 66 83 +

Logic 17 8 +

Syntax 17 8 +_____________________________________________

real requirements

correctspecification

erroneousspecificationRequirements specification specification

correct erroneous design basedcorrectdesign

erroneousdesign on erroneous

specificationDesign

correctprograms

erroneousprograms

programs based on

erroneous design

programs based on erroneous specification

Implementation

correctfunctions

correctableerrors

uncorrectableerrors

hiddenerrors

Test

imperfect

Cumulative effects of error

programs

What Makes a System Unsuccessful?What Makes a System Unsuccessful?

S d l d h did b i i d Systems developed that did not support business strategies and objectivesPoor systems planning and inadequate project managementoo syste s p a g a d adequate p oject a age e tFailure to define or understand user requirements and get users involved in systems developmentN li i ti ti t d b fit f th t j tNegligence in estimating costs and benefits of the system projectCreation of a myriad of defects and errorsAcquisition of incompatible or inadequate technologyAcquisition of incompatible or inadequate technologyNegligence in implementing adequate controlsDevelopment of unstructured, unmaintainable softwareInadequate implementation tasks

What Makes a System Successful?What Makes a System Successful?

l d lStressing user involvement in systems developmentImplementing system planning and using project management t h itechniquesDeveloping alternative systems designs for evaluation before making major commitments to final design technology and making major commitments to final design, technology, and software developmentPreparing clear complete and current documentationPreparing clear, complete, and current documentationUsing a coordinated, planned approach to systems implementationimplementationPerforming postimplementation reviewsDesigning for and performing systems maintenaceDesigning for and performing systems maintenace

Structured System Analysis and D iDesign

What is Structured System Analysis and Design?Major Principles of Structured System Analysis and Design

What is Structured System A l i d D i ?Analysis and Design?

The structured system analysis and design, or structured approach, is a systematic, disciplined, engineered

h d l approach to develop systems.

The goal of the structured system analysis and design g y y gapproach is to create systems that are effective, usable, reliable, and also maintainable.

Larry Constantine and Edward Yourdon are often credited with originating the concept of structured system g g p yanalysis and design in the early and mid-1970s.

Major Principles of Structured System Analysis and DesignMajor principles that are an integral part of the structured system analysis and design approach are:

DecompositionDecompositionModelling tools

Entity-Relationship Diagram (ERD)y p g ( )Data Flow Diagram (DFD)Data Dictionary (DD)Decision TableDecision TableDecision TreeStructured EnglishgStructure ChartStructured Program Flowchart

D t tiDocumentation

E tit R l ti hi Di ERDEntity-Relationship Diagram (ERD)A E tit R l ti hi Di (ERD) i hi l An Entity-Relationship Diagram (ERD) is a graphical representation of data entities (things which can be distinctly identified, or things of importance to a system d st ct y de t ed, o t gs o po ta ce to a systeabout which data needs to be stored) and how they are related to one another.

The ERD was originally proposed by Peter Chen in 1976 and subsequently has been extended by many others, for example Ross Flavin Martin and Date example Ross, Flavin, Martin, and Date.

The ERD is often considered to be the most appropriate d t model be e it pt e mo t of the impo t nt data model because it captures most of the important phenomena of the real world (entities and their relationships) and expresses them in a natural and easily p ) p yunderstandable way.

D Employee

is head of

is inDepartment Employee

runs

works on

Project

produces Reportproduces

An example of entity-relationship diagram

Conceptual Data ModelProject : Publications

hasapplies to

Royalty ScheduleRoyalty Low RangeRoyalty High RangeRoyalty Amount

Titl

Project : PublicationsModel : TutorialAuthor : user Version 1.0 16/11/98

publishesis published by

is sold

hasPublisher

Publisher IDPublisher NameCityState

TitleTitle ISBNTitle TextTitle TypeTitle PriceTitle NotesTitle Publication Date

TitleAuthorTitleAuthor OrderTitleAuthor Percent

correspond to

AuthorAuthor IDAuthor Last NameAuthor First NameAuthor Biography

SaleSale Invoice IDSale DateSale AmountSale TermsSale Quantity

PeriodicalPeriodical Format

NonperiodicalBook collection

takes place in

Author AdvanceAuthor AddressCityStatePostal CodeAuthor Phone Number

Periodical Pub Frequency

is shown in

shows

receivesis given to

DiscountDiscount IDDiscount PercentDiscount TypeLow Quantity

StoreStore IDStore NameCityStatePostal Code

PicturePicture IDPicture

High Quantity Store Address

An example of entity-relationship diagram

DEPARTMENT

1

EMP#

DEPT_EMP

M

EMPLOYEE

ENAME

M

EMP_DEPFIRST MI LAST

1

SALARY

DEPENDENT

M

Chen ERD as shown in his book

MEMBER NONMEMBER PAID1:1

0:M

CUSTOMER

MAKES

1:1

CREDIT CARD

MADE FOR

1:1

TRANSACTION0:1

0:1 0:M

1:1

PURCHASED RENTEDITEMOR RENTED

0:2

1:1

DVD0:M 0:M

IS A COPY OF

DVD PLAYER

MOVIE1:M

Chen ERD as shown in Visio

The notations for drawing ERDs are:1) Entity2) Relationship) a o p3) Cardinality4) Instance participation

1) EntityAn entity is something of importance to a system about which data needs to be stored.

2) RelationshipA relationship is an association or link which shows how one entity or a group of entities relates to another entity or another group of entities.

3) CardinalityIn a relationship, a single instance of the entity, which shares that

l ti hi ti i t i th t l ti hi ti relationship, may participate in that relationship one or many times. The maximum number of times an instance of an entity can participate in a relationship is its cardinality.

The cardinality of a relationship can be either one of these:(1) One-to-one

A relationship whose cardinality is one-to-one relates a single A relationship whose cardinality is one to one relates a single instance of one entity to only a single instance of another entity.

(2) One-to-manyA relationship whose cardinality is one-to-many relates a p y y

single instance of one entity to several instances of another entity.

(3) Many-to-manyA relationship whose cardinality is many-to-many relates several instances of one entity to several instances of another entity.

4) I i i i4) Instance participationIn a relationship, if every instance of the entity, which shares that relationship, must participate in that relationship, the instance

ti i ti f th t tit i id t b d t (t t l) participation of that entity is said to be mandatory (total); otherwise it is said to be optional (partial).

Reflexive RelationshipA reflexive relationship is a relationship p pbetween an entity and itself.

S iSupervises

Employee

Weak Entities (Dependent One-to-Many Relationships)

A weak entities can be identified uniquely only by considering some of its attributes in conjunction with considering some of its attributes in conjunction with the primary key of another entity, which is called the identifying owner.identifying owner.The following restrictions must hold:

The owner entity set and the weak entity set must participate y y p pin a one-to-many relationship set (one owner entity is associated with one or more weak entities, but each weak entity has a single owner) This relationship set is called the entity has a single owner). This relationship set is called the identifying relationship set of the weak entity set.The weak entity set must have total participation in the id tif i l ti hi tidentifying relationship set.

In dependent relationships, the identifier of the non-dependent entity becomes a primary/foreign key in the table generated by the dependent entitytable generated by the dependent entity.The migrated column is integrated into the primary key index if it already exists In this case no new index is index if it already exists. In this case, no new index is generated.

EmployeesDependents

Purchases insurance policy

S /S b (Cl Hi hi I R l i hi )Supertype/Subtype (Class Hierarchies or Is-a Relationship)Inheritance allows you to define an entity as a special case of a more general entity. The entities involved in an inheritance have o e ge e a e y e e es o ed a e a ce a emany similar characteristics but are nonetheless different. The general entity is known as a supertype (or parent) entity and contains all of the common characteristics The special case entity contains all of the common characteristics. The special case entity is known as a subtype (or child), entity and contains all of the particular characteristics.B t titi it i l ibl t d fi i h it li k I Between entities, it is also possible to define an inheritance link. In an inheritance link, one or more subtype (or child) entities inherit, at the physical level, all or part of the attributes carried by one supertype (or parent) entity.

The Account entity below represents all the bank accounts in the information system. It includes two subtypes: checking accounts and savings accounts The subtypes: checking accounts and savings accounts. The notion of inheritance represents the entities Checking and Savings as specialized types of the parent entity g p yp p yAccount. Account

Saving CheckingSaving Checking

Data Flow Diagram (DFD)Data Flow Diagram (DFD)

A d t fl di i di d f if i th A data flow diagram is a diagram used for specifying the movement of data through a system.

A DFD shows where the data flows come from, where they go to, s o s e e t e data o s co e o , e e t ey go to,when they leave the system, where they are stored, what processes transform them, and the interactions between data stores and the processes.p

DFDs are used to depict the dynamic aspects of a system.

Two principle variations of how to draw DFDs are widely used: p p ythat associated with Gane and Sarson, and that associated with Yourdon and DeMarco.

The notations for drawing the DFDs are:The notations for drawing the DFDs are:1) External entity

2) Process2) Process

3) Data flow

4) Data store

(1) E t l tit(1) External entityExternal entities are sources and/or destinations of data flows. They are outside the system being developed. Data flows flow into the system only from external entities and flow out of the into the system only from external entities and flow out of the system only to external entities.

(2) ProcessProcesses transform input data flows into output data flowsProcesses transform input data flows into output data flows.

(3) Data flowA data flow is a data item that is received or transmitted by a process A data flow is represented as a labeled vector into or process. A data flow is represented as a labeled vector into or out of a process. A data flow can flow between an external entity and a process, two processes, or a process and a data store. However, a data flow cannot flow between two external store. However, a data flow cannot flow between two external entities, an external entity and a data store, or two data stores.

(4) Data store( )A data store is where data is kept in order to be used by the processes.

Th Y d /D M t h i diff t The Yourdon/DeMarco technique uses different notations from Gane/Sarson, as shown here:

Object Gane and Sarson

Yourdon and DeMarco

External entity

Data flow

Data storeData store

Process

SA

B

C

21

A

BD

Context Diagram

3

C

EF

3 1 3 2

E F

G

Level 0 Diagram

3.1 3.2

C

The decomposition of a data flow diagramLevel 1 Diagram

AccountingInvoice

Payable summary

Accounts payableVendor

y _ y

Purchase order Vendor infoCheck

Rejected_invoice

Purchase_order, Vendor_info, Stock_receipt

Purchasing

Accounts payable context diagram

Vendor

Purchasing

Purchase_order, Stock_receiptInvoice

Approve invoice

1Update vendor account

2

Vendor_account

Account balance

Account balance

Due_account

Approved invoice

Approved invoice

Check

Rejected invoice

P bl

Prepare vendor check

3

Summarize AP

4

Payable_invoice

Checking balance

Account_balance

Checking register

Purchasing

Vendor info

Payablebalance

Payable summary

Checking_account

g

Accounting

y

Accounts payable level 0 DFD

Data Dictionary (DD)Data Dictionary (DD)

The data dictionary (DD) is an organized listing of all the data elements that are pertinent to the system, with precise rigorous definitions so that both user and precise, rigorous definitions so that both user and systems analyst will have a common understanding.The notations for writing the data dictionaries are:The notations for writing the data dictionaries are:(1) = is composed of(2) + and(2) + and(3) ( ) Optional(4) { } iteration(4) { } iteration(5) [ ] select one of several alternative choices(6) * * comment(6) * * comment(7) | separate alternative choices in the [ ] construct

Examples of data dictionaries:

name = title + first_name + (middle_name) + last_nametitle = [Mr | Miss | Mrs ]title = [Mr. | Miss | Mrs.]first_name = {legal_alphabet}middle name = {legal alphabet}middle_name = {legal_alphabet}last_name = {legal_alphabet}legal alphabet [A Z | a z]legal_alphabet = [A-Z | a-z]

Decision TableDecision Table

A d i i t bl i t i f d l th t A decision table is a matrix of rows and columns that show conditions and actions.A decision table is made up of four sections:A decision table is made up of four sections:1) Conditional statements2) Conditional entries Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 Rule 7 Rule 82) Conditional entries3) Action statements4) Action entries

Condition 1 Y Y Y Y N N N N

Condition 2 Y Y N N Y Y N N)Condition 3 Y N Y N Y N Y N

Action 1 X X X X

Action 2 X X X

Action 3 X

Action 4 X X X

1 2 3 4 5 6

Within 10 days Y Y Y N N N

Over 10,000 Y N N Y N N

5,000 to 10,000 N Y N N Y N

Below 5,000 N N Y N N Y

Take 10% disco nt XTake 10% discount X

Take 5% discount X

Pay full amount X X X X

Decision table for discount authorization

Decision TreeDecision Tree

A d i i t i hi l t ti th t h A decision tree is a graphical representation that shows conditions and actions sequentially and thus shows which conditions to consider first, which second, and so c co d t o s to co s de st, c seco d, a d soon; and it also shows the relationship of each condition and its permissible actions.

C diti

Action

Condition

Condition

Action

Action

Root

Condition

Action

Action

Action

Condition

ConditionAction

Condition

Action

Action

Over 10,000 Take 10% discount

Within 10 days 5,000 to 10,000 Take 5% discount

Below 5,000 Pay full amount

Longer than 10 days Pay full amount

Decision tree for discount authorizationDecision tree for discount authorization

Structured EnglishStructured English

S d E li h i h d bl f bi Structured English is a method to overcome problems of ambiguous language in stating conditions and actions in processes.It is a subset of the full English language with some major t s a subset o t e u g s a guage t so e ajorestrictions on the kind of sentences that can be used and the manner in which sentences can be put together.Its purpose is to strike a reasonable balance between the precision Its purpose is to strike a reasonable balance between the precision of a formal programming language and the causual informality and readability of the English language.Allowable structures1) Sequence2) Decision2) Decision3) Iteration

1) Sequence 3) Iteration) qsentence 1sentence 2

2) Decision

3) Iteration

DO WHILE condition-1sentence 12) Decision

IF condition-1sentence-1

ELSE

sentence-1END DO

REPEATELSEsentence-2

ENDIF

DO CASE

REPEATsentence-1

UNTIL condition-1DO CASECASE variable = value-1

sentence-1CASE variable = value-2

sentence-2sentence-2.CASE variable = value-n

sentence-nOTHERWISEOTHERWISE

sentence-n+1END CASE

P 1 1 3 Ch k C dit A th i tiProcess 1.1.3: Check Credit AuthorizationBEGINtotal_price = 0REAT

ADD quantity_ordered * unit_price * discount to total_priceUNTIL there are no more Order_items in valid_order_detailstotal_price = total_price * (1 + sale_tax_rate)total_price = total_price + shipping_chargescredit_ok = “Yes”_DO CASECASE payment_type = “Cash” or “Check”

IF total price > order paymentIF total_price > order_paymentorder_response = “Purchase price exceeds amout paid”DISPLAY order_responsecredit ok = “No”credit_ok = No

ENDIF

CASE payment_type = “Credit_card”credit_inquiry = “Request for authorization” + total_priceDISPLAY (to credit card agency) credit_inquiry

(f d d ) dACCEPT (from credit card agency) credit_agency_responseIF credit_agency_response = “No”

order_response = “Credit request denied”DISPLAY dDISPLAY order_responsecredit_ok = “No”

ENDIFCASE payment type = “Credit”CASE payment_type = Credit

FIND customer in CUSTOMERS with customer_id = customer_idin valid_order_detailsREAD customer recordREAD customer recordIF customer_balance + total_price > credit_limit

order_response = “Order exceeds your credit limit”DISPLAY order responseDISPLAY order_responsecredit_ok = “No”

ENDIF

END CASEEND CASEIF credit_ok = “Yes”

DISPLAY (to process 1.1.4) valid_order_details + total_price +( p ) pwarehouse_idDISPLAY (to process 1.1.5) valid_order_details + warehouse_id

ENDIFENDIFEND

Structure ChartStructure Chart

S h h h hi h f d l d h Structure chart shows the hierarchy of program modules and the interfaces between the modules. It acts as the design blueprint for software coding and also as a guide to software testing.The Yourdon/Constantine notation shown in Figure below is the most widely used.

EXECUTIVEEXECUTIVE MODULE

MODULE B

MODULE C

MODULE D

MODULE A

MODULE MODULE MODULEMODULE E

MODULE F

MODULE G

Calculate payroll

Pay check

EOF Employee pay record

Gross pay

Gross pay

Net pay

Employee d il

Employee pay record

Compute gross pay

Compute net pay

Print pay check

Get employee

record

p ydetails

Rate

G t l G t t MODULE

Salary amount

Rate and hours

Gross payDeductions

Get salary amount

Get rate and hours

MODULE G

An example structure chart

The notations for drawing the structure charts are:The notations for drawing the structure charts are:1) Module2) Parameter3) Iteration4) Selection1) Module1) Module

A module is an identifiable program unit of the system, such as subprogram, subroutine, or function.Each module has an associated name and can call or be called by Each module has an associated name, and can call or be called by other modules.Modules are shown as rectangles.

2) Parameter2) ParameterParameter symbols represents data or control that are transferred between modules.

There are two types of parameters:- data parameters

Data parameters show data transfer. pData parameters are shown with open circles on their tails.

- control flagsControl flags show the transfer of control informationControl flags show the transfer of control information.Control flags are shown with filled-in circles on their tails.

3) Iteration3) IterationThe iterative symbol represents a calling relationship within a loop construct.The presence of a loop is shown by putting the loop symbol round The presence of a loop is shown by putting the loop symbol round the modules involved.

4) SelectionTh l ti b l ll t l ti hi th t The selection symbol usually represents a relationship that contains an “if” or “case” statement in the calling module.Selection is shown by the small diamond.

Structured Program FlowchartStructured Program Flowchart

d l h f h lStructured Program Flowcharts are one of the earliest modelling tools describing the software logic.In Structured Program Flowchart there are only three basic In Structured Program Flowchart, there are only three basic control constructs used:1) Sequence) q2) Selection3) Repetition

- DO WHILE- DO UNTIL

Sequence

T F

Selection

F

T DO WHILE

TF

DO UNTIL

Basic constructs of Structured Program Flowchart

Object-Oriented Analysis and D iDesign

The Popularity of Object OrientationReasons for Using OO Technologyg gyThe Key Characteristics of Object OrientationUMLUML

The Popularity of Object O i t tiOrientation

A i J 1994 b h Obj M G A survey in January 1994 by the Object Management Group (OMG) indicated that only 3% of IT organizations in the U.S. were using object technology in 1994, but predicted the percentage would grow to approximately 40% by 1997, and 80% by 2001.In five years revenue from the sale of object-oriented software In five years, revenue from the sale of object oriented software is projected to exceed $3 billion, predicts OMG. By 1997, it will be possible to buy 50% of an application as off-the-shelf components effectively doubling productivity (Gartner Group components, effectively doubling productivity (Gartner Group thinks this won’t happen until about 2000). By 1998, early adopters will buy 50% of the application as external components

d i i t ll t d t f th 25% f and reusing internally generated components for another 25% of the application, effectively doubling productivity on an annual basis, and beginning to comply with Mooore’s law for IC chip design.

R f U i OO T h lReasons for Using OO TechnologyP d ti itProductivity

There are strong claims and some impressive anecdotal evident in the computer trade magazines to suggest that system built with object technology can increase the productivity of the project team by as much as a technology can increase the productivity of the project team by as much as a factor of ten, and it can reduce the project’s calendar schedule by as much as a factor of ten.The primary reason why OO projects achieve dramatically higher levels of p y y p j y gproductivity comes from the extensive reuse through libraries of classes and objects; in particular, through the concepts of encapsulation and inheritance.

Rapid System DevelopmentOO software engineers typically have available a robust library or reusable classes and objects, and they can create a specialized subclass of an existing object for their own unique needs through the mechanism of inheritance. This not only reduces the time spent for programming but also for testing This not only reduces the time spent for programming, but also for testing (because the reusable classes and objects have already been tested) and for design (because one doesn’t have to spend time thinking about how to implement the classes and objects). However, the first OO project won’t h h d b d l hshow as much productivity gains as subsequent projects, and several such

projects may be necessary before there are enough reusable components to make a significant difference in the organization’s productivity.

Q litQualityBusiness professionals and developers should have a greater chance of speaking a common language throughout the project. Business people (users) see the world in terms of objects; so a program people (users) see the world in terms of objects; so a program developed in terms of objects should be more intuitive and understandable than a program organized around some other paradigm.It can be said that OO software is more likely to be bug-free than software developed using other methodologies. The greater emphasis on reuse is an important reason for experiencing fewer defects in an OO system; a component that has been reused defects in an OO system; a component that has been reused hundreds of times is more likely to have had the bugs shaken out of it.

MaintainabilityMaintainabilityBecause objects include both data and the behavior associated with the data, changes to data or behavior tend to be localized. The interface with other objects is small and well-defined, and because j ,of encapsulation, the impact of any change on other objects is kept to a minimum.

Wh Obj t O i t ti k ?Why Object Orientation works?

Higher level of abstractionSeamless transition among different phases of g psoftware developmentEncouragement of good programming Encouragement of good programming techniquesPromotion of reusabilityPromotion of reusability

Obj t B iObject Basics

Class: A template for defining the attributes and methods of an object.j

Object: An instance of an object class consisting of attributes and methods. It can represent a person, place, thing, event, or concept Each instance has the same attributes and methods concept. Each instance has the same attributes and methods as other instances of the object class, although it has unique values assigned to its attributes.

Message: A communication from one object to another that requests the receiving object to execute a method. A method call consists of a method name that indicates the requested method and qthe arguments to be used in executing the method. The method call always returns some object to the requesting object as the result of performing the method.object as the result of performing the method.

The Key Characteristics of Object-O i t dOriented

Abstraction: The focus on relevant details while ignoring others. Since objects encapsulate both attributes and methods they work at a higher level of and methods, they work at a higher level of abstraction.

Encapsulation: The hiding of a software object’s internal representation. The object provides an interface that queries and manipulates the data without exposing its underlying structure.p g y g

Inheritance: A mechanism by which an object class can use the attributes and methods defined in classes related to it (its base classes)related to it (its base classes).

Polymorphism: The ability of the same operation to behave differently on different classes.

UMLUMLWhat is UML?History of UMLyUML’s Graphical Diagrams

Wh i UML?What is UML?The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems as documenting the artifacts of software systems, as well as for business modeling and other non-software systems. yThe Unified Modeling Language fuses the concepts of Booch, OMT, and OOSE. The result is a single, common, and widely usable modeling language for users of these and other methods.

Hi f UMLHistory of UMLTh d l t f UML b i O t b f 1994 h G d The development of UML began in October of 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (ObjectModeling T h i ) h d Gi h h B h d OMT h d Technique) methods. Given that the Booch and OMT methods were already independently growing together and were collectively recognized as leading object-oriented methods worldwide, Booch

d b h d f f l f f hand Rumbaugh joined forces to forge a complete unification of their work. A draft version 0.8 of the Unified Method, as it was then called, was released in October of 1995. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method. The Objectory name is now used within Rational primarily to describe its UML-compliant process, the Rational Objectory Process.

UML’ G hi l DiUML’s Graphical Diagrams

UML defines the following graphical diagrams:Use Case DiagramUse Case DiagramClass DiagramBehavior Diagrams:Behavior Diagrams:

Statechart DiagramActivity Diagramy gInteraction Diagrams:

Sequence DiagramCollaboration DiagramCollaboration Diagram

Implementation Diagrams:Component DiagramComponent DiagramDeployment Diagram

U C DiUse Case DiagramA di t ll ti f d t A use-case diagram presents a collection of use cases and actors and is typically used to specify or characterize the functionality and behavior ofU di t i i ti t i ti Use case diagrams contain icons representing actors, association relationships, generalize relationships, packages, and use cases. You can create a top level use-case diagram to visualize the context of a system and the boundaries of the system’s behavior You can of a system and the boundaries of the system s behavior. You can also create one or more use-case diagrams to describe a part of an application system. Use cases can include other use cases as part of their behavior A use-case diagram shows the set of external of their behavior. A use-case diagram shows the set of external actors and the system use cases that the actors participate in.

During: Use Use-Case Diagrams To:Analysis Capture the system requirements and understandAnalysis Capture the system requirements and understand

what the system is supposed to do.Design Specify the behavior of the system as implemented,

and/or specify the semantics of a mechanism

Cl DiClass DiagramA l di i i t f d ibi i d i ti f A class diagram is a picture for describing generic descriptions of possible systems. Class diagrams and object diagrams are alternate representations of object models. Class diagrams contain classes and object diagrams contain objects but it is possible to mix and object diagrams contain objects, but it is possible to mix classes and objects when dealing with various kinds of metadata, so the separation is not rigid. Class diagrams are more prevalent than object diagrams Normally you will build class diagrams plus than object diagrams. Normally you will build class diagrams plus occasional object diagrams illustrating complicated data structures or message-passing structures.Class diagrams contain icons representing classes interfaces and Class diagrams contain icons representing classes, interfaces, and their relationships. During: Use Class Diagrams To:A l i Sh l d ibiliti f thAnalysis Show common roles and responsibilities of the

entities that provide the system's behavior.Design Capture the structure of the classes that form

the system's architecture.

St t h t DiStatechart DiagramSt t h t di d l th d i b h i f Statechart diagrams model the dynamic behavior of individual classes or any other kind of object. They show the sequences of states that an object goes s o t e seque ces o states t at a object goesthrough, the events that cause a transition from one state to another, and the actions that result from a state change state change. Statechart diagrams are closely related to activity diagrams. The main difference between the two gdiagrams is statechart diagrams are state centric, while activity diagrams are activity centric. A statechart diagram is typically used to model the statechart diagram is typically used to model the discrete stages of an object’s lifetime, whereas an activity diagram is better suited to model the

fsequence of activities in a process.

A i i DiActivity DiagramA i i di i i l f di i hi h ll An activity diagram is a special case of a state diagram in which all (or at least most) of the states are action or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or subactivities in the source states. The entire activity diagram is attached (through the model) to a class, such as a use case, or to a package, or to the implementation of an , p g , poperation. The purpose of this diagram is to focus on flows driven by internal processing (as opposed to external events). Use activity diagrams in situations where all or most of the events represent the diagrams in situations where all or most of the events represent the completion of internally-generated actions (that is, procedural flow of control). Use ordinary state diagrams in situations where asynchronous events occurasynchronous events occur.

S DiSequence DiagramA sequence diagram shows an interaction arranged in time sequence. In particular, it shows the instances participating in the interaction by their “lifelines” and participating in the interaction by their lifelines and the stimuli they exchange arranged in time sequence. It does not show the associations among the objects.g jA sequence diagram has two dimensions: 1) the vertical dimension represents time and 2) the horizontal dimension represents different objects. Normally time proceeds down the page. (The dimensions may be reversed if desired )reversed, if desired.)

C ll b i DiCollaboration DiagramA ll b ti di i i t ti di th t h th A collaboration diagram is an interaction diagram that shows the sequence of messages that implement an operation or a transaction. C ll b i di h bj h i li k d h i Collaboration diagrams show objects, their links, and their messages. They can also contain simple class instances and class utility instances. Each collaboration diagram provides a view of the i t ti t t l l ti hi th t b t bj t interactions or structural relationships that occur between objects and object-like entities in the current model.A collaboration diagram shows an interaction organized around the

l i th i t ti d th i li k t h th U lik roles in the interaction and their links to each other. Unlike a sequence diagram, a collaboration diagram shows the relationships among the objects playing the different roles. On the other hand, a collaboration diagram does not show time as a separate dimension collaboration diagram does not show time as a separate dimension, so the sequence of interactions and the concurrent threads must be determined using sequence numbers.

During: Use Collaboration Diagrams To:Analysis Indicate the semantics of the primary and secondary

interactions Design Show the semantics of mechanisms in the logical design of

the system

Use collaboration diagrams as the primary vehicle to describe interactions that express your decisions about the behavior of the systemsystem.

C DiComponent DiagramC di id h i l i f h Component diagrams provide a physical view of the current model. A component diagram shows the organizations and dependencies among software organizations and dependencies among software components, including source code components, binary code components, and executable components. These diagrams also show the externally-visible behavior of the components by displaying the interfaces of the components Calling dependencies among components components. Calling dependencies among components are shown as dependency relationships between components and interfaces on other components. Note that the interfaces actually belong to the logical view, but they can occur both in class diagrams and in component diagramscomponent diagrams.

Component diagrams contain:Component packagesComponentsInterfacesDependency relationships

You can create one or more component diagrams to depict the component packages and components at the top level of the component view, or to depict the contents of each component package Such component contents of each component package. Such component diagrams belong to the component package that they depict.depict.

D l DiDeployment DiagramA deployment diagram shows processors, devices, and connections. Each model contains a single deployment diagram which shows the connections between its processors and devices, and the allocation of its processes to processors.