Slides of Software Engineering Consortium

8/18/2019 Slides of Software Engineering Consortium

1/610

© 2004 by SEC

Introduction to Software Engineering

Software Engineering Consortium

(SEC)


2/610

2

© 2004 by SEC

Preface and Introduction (cont’d)

The objective of this course is to explain the Introduction ofsoftware engineering , and provide an eas and practicalintroduction to the important characteristics of softwareengineering! "fter ta#ing this course, students will understand

$ what is software engineering% $ wh software engineering is important%

$ how to develop software and manage a software project b using thesoftware engineering in detail!


3/610

3

© 2004 by SEC

Preface and Introduction (cont’d)

This courseware is designed for a semester&long for junior orsenior undergraduate students, and for the industrial parties!The following professors contribute to the development ofthis courseware'

$ onathan ee, *h+! (李允中 ) $ Chung&Shan iu, *h+! (留忠賢 )

$ !&! -uo, *h+! (郭忠義 )

$ Chien&.ung iu, *h+! (劉建宏 )

The /inister of Education sponsors this coursewaredevelopment!


4/610

4

© 2004 by SEC

Prerequisites

Introduction to Computer Science

*rogramming S#ills


5/610

5

© 2004 by SEC

Contents

Chapter 0! "n 1verview of Software Engineering

Chapter 2! Software *rocesses

Chapter 3! 4e5uirements Engineering

Chapter 6! Software +esign

Chapter 7! 1bject&1riented Software +evelopment

Chapter 8! Software Testing

Chapter 9! Software *roject /anagement and *lanning

Chapter :! Software ;ualit "ssurance

Chapter

Chapter 0=! >ormal /ethods and Software Engineering

Chapter 00! "dvanced Topics in Software Engineering


6/610

© 2004 by SEC

!eferences

?*ressman 2==6@ 4oger S! *ressman! Software Engineering' a practitionerAsapproach, 8th edition! /cB4"&.I!

?Sommerville 2==6@ Ian Sommerville! Software Engineering, 9th edition! "ddisonesle!

?4umbaugh et al!0


7/610

"

© 2004 by SEC

!eferences (cont’d)

?DeiHer 0


8/610

© 2004 by SEC

C#a$ter %&n 'eriew of Software Engineering


9/610

© 2004 by SEC

C#a$ter %&n 'eriew of Software Engineering

0!0 Software Crisis

0!2 Software /ths

0!3 Software Engineering *aradigm

0!6 The Evolution of Software Engineering

0!7 Software Engineering in Taiwan


10/610

%0

© 2004 by SEC

*#at is t#e Prob+e,-

:6 J of all software projects do not finish on time and within budget (Surve conducted b Standish Broup)

$ :=== projects in KS in 0


11/610

%%

© 2004 by SEC

!ea+ Cases

Dan# of "merica /aster et Sstem

$ Trust business! 0


12/610

%2

© 2004 by SEC

Prob+e,s of Software

Beneral issues

$ . vs! S

$ *roductivit' build new programs from scratch

$ /aintenance' maintain existing programs

Essence vs "ccidental (>! Droo#s)


13/610

%3

© 2004 by SEC

./ roo1s’ Essence

Essence' the difficulties inherent in the nature of software $ Complexit' development process, application domain, internals of the

sstem (e!g!, number of states, siHe of software, functionalit,structures, and behaviors)!

$ Conformit' software must adapt to interact with people according to

their diverse needs% therefore, software cannot be completelrepresented formall!

$ Changeabilit' software component is usuall the easiest one tomodif% (application changes, software changes)!

$ Invisibilit' software structure is hidden, onl behavior can be

observed when executing the software!


14/610

%4

© 2004 by SEC

./ roo1s’ &ccidents

"ccident' difficulties arise in representing, testing theconceptual constructs (S) (e!g!, software development

process), examples of accidental difficulties'

$ accidental complexit' abstract program vs concrete machine program%

solved b .! $ slow turnaround' batch programming vs time&sharing (shortest

response time)% solved b time&sharing!

$ no standard formats' individual programs vs integrated librar,standard formats% solved b unified programming environment!


15/610

%5

© 2004 by SEC

C#aracteristics of Software

Software Hardware

logical sstem element

developedLengineered

ot ware out but deteriorate

Ksuall custom&built

phsical sstem element

manufactured

ware out

assembled from existing

component

- no spare parts &es, with spare parts


16/610

%

© 2004 by SEC

Software yt#s (cont’d)

/anagement /ths

$ e alread have a boo# thatAs full of standards and procedures for building software! onAt that provide m people with everthing theneed to #nowM

$ / people do have state&of&the&art software development tools% afterall, we bu them the newest computers

$ If we get behind schedule, we can add more programmers and catch up


17/610

%"

© 2004 by SEC


Customer /ths

$ " general statement of objectives is sufficient to begin writing programs $ we can fill in the details later

$ *roject re5uirements continuall change, but change can be easilaccommodated because software is flexible


18/610

%

© 2004 by SEC


*ractitionerAs /ths

$ 1nce we write the program and get it to wor#, our job is done

$ Kntil I get the program NrunningO I reall have no wa of assessing its5ualit

$ The onl deliverable for a successful project is the wor#ing program


19/610

%

© 2004 by SEC

*#at is Software Engineering-

4eal orld Software orld

Software Engineering


20/610

20

© 2004 by SEC

Software Engineering Paradig,

Software engineering is a discipline that integrates methods,tools, and procedures for the development of computersoftware!

$ /ethod' introduce a wa to build S

$ Tool' automatic, semi&auto support for methods

$ *rocedure' define the se5uence in which methods will beapplied, the controls that help ensure 5ualit and coordinate

changes!


21/610

2%

© 2004 by SEC

Software Process

aterfall life ccle

*rototping

Spiral model

"utomatic snthesis model 1bject&oriented model

6 B model


22/610

22

© 2004 by SEC

raditiona+ Software Engineering

Software Sstems

+ata>unction Dehavior

Entit&4elation+iagram

+ata >low+iagram

State Transition+iagram


23/610

23

© 2004 by SEC

'bect6'riented Software Engineering

Software Sstems

>unction1bject Dehavior

+ata >low+iagram

Class+iagram

State Chart


24/610

24

© 2004 by SEC

Software Industry

Independent *rogramming Service

Software *roduct

Enterprise Solution

*ac#aged Software for the /ass Internet Software and Services


25/610

25

© 2004 by SEC

Inde$endent Progra,,ing Serices

(Era %) >eb 0irst Software Compan that devoted to the construction ofsoftware especiall for hardware compan!

*romoting Software Industr' two /ajor *rojects,

$ S"D4E, airline reservation sstem, P3= million!

$ S"BE, air defense sstem (0


26/610

2

© 2004 by SEC

Software Product (Era 2)

0lowchart Software &&"utoflow for 4C", but rejected!

Sale to the customer of 4C" F ID/!

+evelop and mar#et software products not specificall designed

for a particular hardware platform! $ /"4- I, a pre&runner for the database management sstem!

ID/ unbundled software from hardware!


27/610

2"

© 2004 by SEC

Enter$rise So+utions (Era 3)

+ietmar .opp! ID/ Berman

$ Sstems, "pplications and *roducts (S"*) P3!3billion (0


28/610

2

© 2004 by SEC

Pac1aged Software for t#e asses(Era 4)

Software products for the masses! 0 $ isiCalc, Spreadsheet program!

"ugust 0


29/610

2

© 2004 by SEC

Internet Software and Serices (Era 5)

Internet and value&added services period, 0


30/610

30

© 2004 by SEC

I ar1et

Hardwareproducts

Hardwaremaintenance

Software Products& Services

Processing Servicesand Internet Services

EmbeddedSoftware

ProfessionalService

SoftwareProducts

EnterpriseSolution

PackagedMass-MarketSoftware


31/610

3%

© 2004 by SEC

Software Products and Serices

EnterpriseSolutions

IBMOracleComputer AssociatesSAPHPFujitsu

HitachiParametric Technolo!People SoftSiemens

Packaged Mars-MarketSoftware

MicrosoftIBMComputer AssociatesAdo"e#o$ellS!mantec

IntuitAutodes%Apple

The &earnin Compan!

Professional SoftwareServices

Anderson ConsultinIBM'(SCSCScience ApplicationsCap )emini

Hp('CFujitsuBSO Oriin


32/610

32

© 2004 by SEC

E7ercises

*lease find the definition of Software Engineering from thetext boo#s, papers, and Internet as man as possible!

*lease surve the software engineering application inindustries of T"I"!


33/610

© 2004 by SEC

C#a$ter 2Software Process ode+


34/610


35/610

35

© 2004 by SEC

C#a$ter 2Software Process ode+ (cont’d)

2!3 Beneric iew of Software Engineering

2!6 Comparison of Software +evelopment *rocesses

2!7 "dvanced Topics

2!7!0 C//LC//I2!7!2 /odel +riven +evelopment

2!7!3 Extreme *rogramming

2!7!6 "gile /ethod

Exercises


36/610

3

© 2004 by SEC

Introduction to Software Process

4e5uirement ac5uisition (problem statements)

$ to describe the problem to be solved and providing a conceptualoverview of the proposed sstem

4e5uirement analsis

4e5uirement specification

Sstem analsis

Sstem design


37/610

3"

© 2004 by SEC

Introduction to Software Process (cont’d)

+etail design

Coding

Testing /aintenance


38/610

3

© 2004 by SEC

!equire,ent &na+ysis

" process of discovering, refinement, modeling andspecification!

$ *rinciples' represent information domain of a problem

information flow' data F control changes

information content' composite term!

information structure' organiHation

$ /odeling' (graphical F textual description)

modeling methods' S", 11", S+, +SS+, S"+T

model component' information, function, behavior


39/610

3

© 2004 by SEC

!equire,ent &na+ysis (cont’d)

$ "rtifact

4e5uirement specification!

$ capturing' functionalit, behavior, and structure


40/610

40

© 2004 by SEC

8esign

The problem is decomposed into modules

The interface between modules must be specified

+efine architecture "rtifact' design model

$ +ata design

data abstraction, data structure, data modeling

*rocedural design' iteration , conditional, se5uence

"rchitectural design' program structure, software architecture)


41/610

4%

© 2004 by SEC

I,$+e,entation

Individual module programming

$ *seudo&code

The goals $ the development of a well&documented

$ The reliable, eas to read, flexible, correct program

Integration of modules

"rtifact' executable program


42/610

42

© 2004 by SEC

esting

Test the sstem from requirement engineering toim#lementation

$ erification and validation

"rtifact' testing report


43/610

43

© 2004 by SEC

aintenance

/aintain the user satisfaction

$ 4epair errors, re5uirements changed or extended

Changes in both the sstemAs environment and user

re5uirements are inevitable $ /aintenance R Evolution


44/610

44

© 2004 by SEC

aintenance (cont’d)

-inds of maintenance activities

$ Corrective

$ "daptive

$ *erfective

$ *reventive

Definition Development After release

1x

1.5-6x

60-100x

The Impact of Chane


45/610

45

© 2004 by SEC

Software 9ife Cyc+e

aterfall model

*rototping

Incremental model Spiral model

>ourth&generation techni5ues

Knif process model

"utomatic software snthesis


46/610

4

© 2004 by SEC

*aterfa++ ode+

>re5uentl implemented based on a view of the worldinterpreted in terms of a functional decomposition!

$ hat does the sstem doM

Dased on functional decomposition!

$ top&down analsis and design methodolog

$ S"LS+

based on data flows ' +>+, ++, structure charts!

$ easil to map to conventional procedural language

* f ++ d + ( ’d)


47/610

4"

© 2004 by SEC

:ser !equire,ents

&na+ysis

:ser !equire,ents

S$ecification

Software !equire,ents

S$ecification

Syste,;oard 8esign

9ogica+ 8esign

Progra,;8etai+ed 8esign

P#ysica+ 8esign

i,$+e,entation;Coding

Progra, esting < :nits

Progra, esting<

syste,

Progra, :se

software aintenance

*=&

='*

&>&9?SIS

8ESI@>

:I98

*aterfa++ ode+ (cont’d)


48/610

4

© 2004 by SEC

Throwawa ' implement onl aspects poorl understood!

Evolutionar ' more li#el to implement best understood benefits '

$ improve communication

$ reduce ris#

$ most feasible wa to validate specification

$ for maintenance as well!

Prototy$ing ode+


49/610

4

© 2004 by SEC

The roles of prototping

$ as a means to ac5uire validate users re5uirements!

$ as scaled&down version of the final operational sstem!

$ as a means to validate solution specifications!

$ as a solution specification for design and implementation

Prototy$ing ode+ (cont’d)


50/610

50

© 2004 by SEC

S!stemImplementation

(etermine*e+uirements

ConstructProtot!pe

(emonstrateProtot!pe

*e+uirements

*e+uirementsAdjustments

Protot!pe

O,

Prototy$ing ode+ (cont’d)


51/610

5%

© 2004 by SEC

S$ira+ ode+

Spiral model

$ 4is# driven

$ Throwawa prototping


52/610

52

© 2004 by SEC

Progresst#roug#

ste$s

Cu,u+atiecost

8eter,ineobectiesAa+ternatieAconstraints

!is1 ana+y6sis

Prototy$e

!is1

ana+ysis

!is1 ana+ysis

!is1 ana+ysis

% 2 3Prototy$e Prototy$e '$erationa+

Prototy$eSi,u+ationsA ,ode+sA benc#,ar1s

8etai+eddesign

Code:nittest

Integrationand test&cce$tance

testI,$+e,en6tation

8esign a+idationand erification

Software$roduct

design

Softwarerequire,ent

!equire,ent

a+idation

8ee+o$,ent

$+an

Integrationand test $+an

P+an ne7t $#ases

8ee+o$A erifyne7t6+ee+ $roduct

Ea+uate a+ternatiesidentifyA reso+e ris1s

!equire,ents $+an+ife6cyc+e $+an!eiew

Co,,it,ent

$artition

S$ira+ ode+ (cont’d)


53/610

53

© 2004 by SEC

S$ecification&cquisition

S$ecification

Ba+idation

aintenance

#ig#6+ee+

s$ecification

($rototy$ing)

Interactierans+ation

&uto,aticCo,$i+ation

source

$rogra,

infor,a+

s$ecification

decision

rationa+

+ow6+ee+

s$ecification

for,a+

dee+o$,ent

uning

&uto,ated Synt#esis ode+


54/610

54

© 2004 by SEC

4e5uirements

gathering

+esign

strategimplementation

using 6B

Testing

.ourt#6generation ec#niques


55/610

55

© 2004 by SEC

'bect6'riented &$$roac#

11" emphasiHes on finding and describing the o)*ects & orconce#ts & problem domain!

11+ emphasiHes on defining logical software object thatwill ultimatel be implemented in an object&oriented

programming language!

11* (*rogramming), implements the designed componentsin C, ava!


56/610

5

© 2004 by SEC

''& ''8 ''P

:ser’s Pers$ectie 8ee+o$er’s Pers$ectie

Develop modelof requirements

Add detail and

design decisions Develop code

oat

age

*ublic class Doat public void sail() private +ate age%

U

'bect6'riented &$$roac# (cont’d)

'bect 'riented &$$roac# (cont’d)


57/610

5"

© 2004 by SEC

aintenance .urt#er8ee+o$,ent

:nitesting

CodingProgra, 8esign

Software!equire,entsS$ecification

:ser!equire,entsS$ecification

!equire,ents&na+ysis

Syste,8esign

Syste,esting

Progra,

:se

bottom&up' develop anindividual class

top&down analsis

'bect6'riented &$$roac# (cont d)


58/610

5

© 2004 by SEC

@eneric Biew of Software Engineering

+efinition' hat

+evelopment' .ow

/aintenance' Change


59/610

5

© 2004 by SEC

aterfall model problems

$ traceabilitLlanguages in different phases

$ *rocess is too linear

re5uirement ac5uisition and validation

$ maintainabilit ' due to the use of functional decomposition

$ assume full elaborated documentation at the earl stage of the lifeccle!

reusabilit ' top&down design

communication

Co,$aring Barious ode+s


60/610

0

© 2004 by SEC

$ based on functional decomposition

Strongl dependent on detailed functional brea#down

not consider evolutionar changes!

not encourage reusabilit

*rototping (partial implementation )

$ Denefits

improve communication

Co,$aring Barious ode+s (cont’d)


61/610

%

© 2004 by SEC

$ reduce ris#

$ communication between developments

$ determine a proposed designAs un#nown properties

$ address re5uirement ac5uisition and validation limitation $ provide a basis for assessing the feasibilit and

performance of alternative designs

$ most feasible wa to validate specification!

$ for maintenance as well

$ imitation

5uic# and direct approach without considering issues such as5ualit and maintainabilit!



62/610

2

© 2004 by SEC

verif correctness

and completeness

of design or

implementation

interconnections

during

architecture and

module design

containing

5uantifies

prototping

lang!specification

language

+esignlanguage

executablesupporting

formal

reasoning

low

priorit

detailalgorithmand datastructure

no

no

no

es

notnecessar

must

no

es

not

programminglanguage

efficient

anguage



63/610

3

© 2004 by SEC

longevit

t= t0 t2 t3 t6 t7

.unctiona+ity

i,e

inappropriateness

lateness

shortfall

slop ' adaptabilit

original re5t!

"

D

+

C

E

waterfallmodel

1 ' (t=) original re5t!

" ' ( at t0) an operational product, not satisfing the old to needs

because poor understanding of needs!" & D ' undergo a series of enhancements!

D & + ' the cost of enhancements increase, to build a new sstem!

stop at t6!

V ccle repeat itself



64/610

4

© 2004 by SEC

before understanding

of the userWs need RX

increase in functionalit

t= t0 t2 t6

>unctionalit

Time

#rowaway Prototy$ing and S$ira+ ode+


65/610

5

© 2004 by SEC

Timet= t0 t2 t6

>unctionalit

Eo+utionary Prototy$ing


66/610

© 2004 by SEC

t t. t/ t0

Functionalit!

t1

Time

&uto,ated Software Synt#esis


67/610

"

© 2004 by SEC

t= t0 t2 t6

>unctionalit

Time

user

4eusable Software

approach

conventional

approach

!eusab+e Software ersus Conentiona+


68/610

© 2004 by SEC

+o ou thin# NcomplexitOand NchangeOis the problems ofsoftware developmentM hM

Comparison of different software engineering paradigms '

waterfall, prototping, spiral, 11C, 6B

$ prototpe ' both specification and design

$ program ' optimiHation

E7ercise


69/610

© 2004 by SEC

Issues in using different #inds of language in waterfallmodel

different phases need different #inds of languages

transformation between languages at different phases! main features of each language

$ specification, design, prototpe, program

$ specification ' abstract of sstem functionalit

$ design ' abstract of sstem structure $ prototpe ' both specification and design

$ program ' optimiHation

E7ercise (cont’d)


70/610

© 2004 by SEC

C#a$ter 3!equire,ents Engineering


71/610

C#a$ter 3


72/610

"2

© 2004 by SEC

C#a$ter 3!equire,ents Engineering (cont’d)

3!3 1bject&oriented (11) software engineering 3!3!0 Steps of analsis' an example using 11 approach

3!3!2 Concepts and phenomena

3!3!3 Class and class identification

3!3!6 *ieces of an object model3!6 +ata modeling and 11"

3!6!0 +ata modeling and 11"

3!6!2 Software artifacts

3!6!3 1bject 1rientation

3!6!6 *olmorphism

3!6!7 1/T methodolog

3!6!8 >eatures of object orientation' DlairAs version


73/610

"3

© 2004 by SEC

3/% !equire,ents Engineering


74/610

"4

© 2004 by SEC

4e5uirement

$ >unctional re5uirement describes sstem services or functions

$ on&functional re5uirement is a constraint or a goal on the sstem or onthe development process

Kser (Customer) re5uirement

$ " statement in natural language plus diagrams of the services the sstem provides and its operational constraints

4e5uirements specification

$ " structured document for detail description of the sstem services!

$ ritten as a contract between client and developer

Software !equire,ents


75/610

"5

© 2004 by SEC

Incomplete 4e5uirements $ /ost software sstems are complex, that developer can never full

captured during the sstem development, therefore, re5uirements arealwas incomplete!

Inconsistent 4e5uirement

$ +ifferent users have different re5uirements and priorities! There is aconstantl shifting compromise in the re5uirements!

$ *rototping is often re5uired to clarif re5uirements!

C#aracteristics of !equire,ents


76/610

"

© 2004 by SEC

4e5uirements elicitation $ +etermine what the customer re5uires

4e5uirements analsis

$ Knderstand the relationships among various customer re5uirements

4e5uirements negotiation

$ Shape the relationships among various customer re5uirements toachieve a successful result

$ 4esearch on re5uirements trade&off analsis (formulating as goals)

4e5uirements specification

$ Duild a form of re5uirements

!equire,ents Engineering


77/610

""

© 2004 by SEC

Software modeling $ Duild a representation of re5uirements that can be assessed for

correctness, completeness and consistenc!

4e5uirements validation

$ 4eview the model

4e5uirements management

$ Identif, control and trac# re5uirements and the changes!

!equire,ents Engineering (cont’d)


78/610

"

© 2004 by SEC

!equire,ents E+icitation

Two sources of information for the re5uirements elicitation process

$ Kser (customer)

$ "pplication domain

"s#ing $ "s# users what the expect from the sstem

$ Interview, brainstorm and 5uestionnaire

Tas# analsis

$ .igh&level tas#s can be decomposed into sub&tas#s

Scenario&based analsis

$ Stud instances of tas#s

$ " scenario can be real or artificial


79/610

"

© 2004 by SEC

!equire,ents E+icitation (cont’d)

>orm analsis $ " lot of information about the domain can be found in various forms

(examples in E4+ slides)

$ >orms provide us with information about the data objects of the domain,

their properties, and their interrelations atural language description

$ with bac#ground information to be used in conjunction with otherelicitation techni5ues such as interviews

+erivation from an existing sstem $ Ta#e the peculiar circumstances of the present situation into account

(examples in E4+ slides)

*rototping


80/610

0

© 2004 by SEC

3/2 !equire,ents &na+ysis



81/610

%

© 2004 by SEC

Information domain analsis

$ information flow' data transformation $ data content' data dictionar

$ data modeling

>unctional and behavioral representation

$ function' process transformation $ behavior' state transition diagram

Interfaces definition

$ functionLprocess interface

*roblem partition and abstraction $ at different levels of abstraction

$ classification and assembl structure



82/610

2

© 2004 by SEC

*urpose $ focus on those 5ualities of an entit that are relevant to the solution

of an application problem

$ abstract awa those that are irrelevant

/odel' an abstraction for $ Knderstanding before (actuall) building

$ Communication

$ isualiHation

$ 4educing complexit

/ethodolog' build (analHe) a model of an applicationdomain

Software ode+ing


83/610

3

© 2004 by SEC

&$$+ication and So+ution 8o,ain

"pplication +omain (4e5uirements "nalsis) $ The environment in which the sstem is operating

Solution +omain (Sstem +esign, 1bject +esign)

$ The available technologies to build the sstem


84/610

4

© 2004 by SEC

the problemthe problemrequirementsrequirements

elicitationelicitation

build abuild aprototypeprototype

createcreateanalysisanalysismodelsmodels

developSpecification ReviewReview

#e &na+ysis Process


85/610

5

© 2004 by SEC

raditiona+ Software Engineering

Software Syste,s

+ata>unction Dehavior

Entit&4elation

+iagram

+ata >low

+iagram

State Transition

+iagram

.ro, &na+ysis to 8esign< &


86/610

© 2004 by SEC

'*( (F(

(ata"ase Ta"les

Screen2

*eport

Structuredchart

Structured'nlish

.ro, &na+ysis to 8esign< &raditiona+ &$$roac#


87/610

"

© 2004 by SEC

Entit

$ *rimar things an organiHation collects and records informationabout! (noun) ( )

E!g! persons, products, places, etc!

4elationship

$ in#age between entities! (verb) ( )

E!g! *ersons perform jobs, obs consist&of tas#s

Cardinalit

$ Identif how man instances of one entit are related to how maninstances of another entit!

Entity6!e+ations#i$ 8iagra,


88/610

© 2004 by SEC

$ +irection using an arrow pointing to the object of the action!

Examples

Persons

3o"s

Perform

Customers

Tas%s

Ser$e

Consist-of

.4. Persons

3o"s

.4#consist5of

3o"s

Tas%s

M4#ser$ePersons

Customers

Entity6!e+ations#i$ 8iagra, (cont’d)

perform


89/610

© 2004 by SEC

"ttributes' *roperties to describe an entit

$ #e attribute (#e, identifier) to characteriHe the specific entit (toretrieve a single entit occurrence (instance))

unique' to ensure that no other record has the same identifier!

unc#anging' to ensure that it alwas refers to the same thing!

Students Faculty

Courses

Assist Advice

TeachTake




90/610

0

© 2004 by SEC

$ Student is an entit about which a universit stores info such as theStudentYid, name, and phone!

Compound #es' made up of a number of different sub#esto produce a uni5ue identifier

$ e!g! course number section number term

The difference between an entit and an attribute is thatattributes are atomic!

$ i!e! "ttributes have no further attributes that describe them! Entitiescan be further described b their attributes!

5041693 !oakes"" #ane $4$%&14&

&14$6006 'lou(h" #) 4$6%4141

*ntity type +ey attri,ute Attri,ute

*ntity

occurrence

actual data

Students

Student-idna.e phone

e!g!

Entity !e+ations#i$ 8iagra, (cont d)


91/610

%

© 2004 by SEC

-ernel and characteristic entities $ Entities can be described b other subsidiar entities in a

hierarchical fashion!

to store related values of one of the attributes of an entit!

Courses

Sections

Meetins

*ntities +eys Attri,utes

Course-id

Course-id

Section-id

Course-id

Section-id

/eetin(-id

na.e

credits

Faculty

/eetin(-day

/eetin(-ti.e

oo.

&danced .eatures


92/610

2

© 2004 by SEC

$ The highest entit tpe in the hierarch is called a #ernel entit,which has a uni5ue identit that does not depend on the existence ofan other entit tpe!

$ Characteristic entities' to record the repeated characteristics of the#ernel entit!

e!g! Course is a #ernel entit, Sections and /eetings arecharacteristic entities describing the characteristics of Courses!

The uni5ue identifier for the characteristic entities is a multiple#e!

e!g! CourseYid SectionYid are needed to uni5uel identif asection!

&danced .eatures (cont’d)


93/610

3

© 2004 by SEC

$ 4ecursive relationships' an entit is related to itself

e!g!

$ for retrieving all famil relationships

erson

2s-/arried-To

2s-arent-of

2s-Child-of



94/610

4

© 2004 by SEC

$ &ar relationships

$ e!g!

"n example

Faculty

oo.s

/eetin(s

Sections

StudentsCourses

)ccupy

Teach Take

Contain

ave


*#ere to +oo1 for infor,ation-


95/610

5

© 2004 by SEC

$ existing forms

forms organiHe the data and remind what to collect!

It is common in manual sstems to provide large amounts ofredundant data!

e!g! Scholarship "pplication >orm

Scholarships

Students

eferees

eference etters

euested for.

7na.es and addresses8

na.es of Scholarship

applied for

Student nu.,er -----

na.e -------- ear of pro(ra. ----

:A ---

reuest

Apply for eceive

$ Existing file structures

> tl i ti h ll ti f li ti


96/610

© 2004 by SEC

>re5uentl organiHations have a collection of application programsthat do not lin# to each other! The ma re5uire complex programsto transform data used b one application into a form used b

another one! e!g! existing student record sstem

Accounts: Account_id, Label

Buildings: Building_id, Name, Address.

ourses: ourse_id, ourse_Name, redits.

ourse_!rogram: ourse_id, !rogram_id"epartments: "epartment_id, "epartment_Name.

#nrolled: $tudent_id, ourse_id, $ection_id, %ear, &erm, 'rade.

(aculty: (aculty_id, Name, Address, Birthday.

(ee_!ayments: $tudent_id, Account_id.

!rerequisites: ourse_id, !re), !re*, !re+.

!rograms: !rogram_id, !rogram_Name.Rooms: Building_id, Room_id, $ie, &ype.

$ections: ourse_id, $ection_id, %ear, &erm, (aculty_id -eeting_id,

Building_id, Room_id, "ay, &ime/ ...

$tudents: $tudent_id, Name, Address, Birthday.


97/610

"

© 2004 by SEC

-ernel entities' single #es, such as' "ccounts, Duildings,Courses, +epartments, >acult, *rere5uisites, *rograms,

and Students Characteristic entit vs! 4elationship (rules)

1erne+ entity (or characteristic entit)As #e not part of the #eof an entit

RX characteristic entit ,u+ti$+e 1eys are combinations of #es for other entities RX /'

relationships

$ e!g CourseYprogram' courseYid, programYid!!!

Enrolled' studentsYid, courseYid,!!! $ e!g 4ooms' buildingYid Z&&&& from buildingAs

roomYid Z&&& not identified precisel

characteristic entit

E!8 fro, E7isting .or,s and .i+es


98/610

© 2004 by SEC

Buildins

*ooms

Meetins

Facult!

Accounts

Students

Sections

(epartments

*eferees

Scholarships

Courses

Prorams

course-prora

applied-for

recei$e

fee-pa!ment

E!8 fro, E7isting .or,s and .i+es

esting E!8


99/610

© 2004 by SEC

o identification #e for entit

Two or more entities have the same #e

/an relationships to a single entit

Two or more relationships between the same entities &ar relationship

"n entit has no relationship

esting E!8

E t d d E tit ! + ti #i d +


100/610

%00

© 2004 by SEC

E7tended Entity6!e+ations#i$ ode+

To define the logical content of the database Extension in two dimensions'

$ to document the attribute of each entit

$ to document the semantic meaning of the relationships

8efine


101/610

%0%

© 2004 by SEC

8efine&ttributes

"ttributes' an elementar item of recordable data that cannot be further subdivided into meaningful data items! (>ield ordescriptor)

$ with two distinguishing features'

atomic fact' an attribute cannot have attributes of its own! single value' an attribute cannot have more than one value for an

single entit occurrence!

If there is more than one value for the same entit occurrence, anew characteristic entit must be created to contain the multiple

values!

8 fi &tt ib t ( t’d)


102/610

%02

© 2004 by SEC

$ *rimar #e' to identif uni5uel each occurrence of an entit, withthe following properties'

uni5ue

unchanging

never has a null or missing value can have more than one attribute to create a uni5ue #e!

$ a single attribute' an atomic #e!

$ multiple attributes' a compound #e!

dataless #es are not subject to change in the wa that #esmade up of data items often do!

$ "lternate #e' to provide a choice of identifiers!

8efine &ttributes (cont’d)



103/610

%03

© 2004 by SEC

$ >oreign #e' to create a lin# with another entit, e!g!*41B4"/YI+ is a foreign #e lin#ing STK+ETS to*41B4"/S!

$ ull 1-' to indicate whether this attribute can ever have a nullvalue!

if an attribute does not exist for some occurrences of an entit!

if it exists but is not #now at the time the entit occurrence isrecorded!

foreign #e can have a null value if the relationship that the

map is optional! $ Tpe' tpes of attributes!

$ idth' max number of characters or digits!




104/610

%04

© 2004 by SEC

$ Example'

Entit STK+ETS

"TT4IDKTE *4I/"4

-E

>14EIB

-E

K

1-

T*E I+T.

STK+ETYI+

SK4"/E

>I4ST"/E

*41B4"/YI+

[

[

I+

C."4

C."4

I+

<

2=

2=

<


S i f # ! + i #i


105/610

%05

© 2004 by SEC

4elationships $ Extension to allow for

o$tiona+ity' to determine whether the lin#ed entities mustalwas be lin#ed!

e7istence de$endency' to determine whether the existence ofan entit occurrence depends on the existence of an occurrenceof anther entit!

abstractions' permit the definition of a hierarch of entitieswith rules about how the levels of the hierarch are related!

Se,antics of t#e !e+ations#i$s



106/610

%0

© 2004 by SEC

1ptionalit' $ /andator' If the relationship between entities " and D is

mandator, then each instance of " must correspond to an instanceof D

$ +#tional: If it is o#tional at the end of A, then some instance of A

can )e recorded that has no relationshi# to any instance of (

$ e!g!

ST;!*


107/610

%0"

© 2004 by SEC

Existence +ependenc $ to describe the relationship between characteristic entities and

#ernel entities

C);S*

C);S*S*CT2)


108/610

%0

© 2004 by SEC

"bstractions $ the more specific entities inherit the properties of the more abstract

entities

specific entities are collected into subtpes that share common properties with the more general entit, called a supertpe

$ overlapping subtpes (or aggregation relationship)

IS&*"4T&1> ( )

e!g!

optional"T.ETES /KSICI"S

STK+ETS

$(cont’d)



109/610

%0

© 2004 by SEC

/utuall exclusive subtpes (or generaliHationrelationship)

IS&" ( )

e!g!

existence dependenc

STK+ET

K+E4 B4"+K"TES

Se,antics of t#e !e+ations#i$s(cont’d)



110/610

%%0

© 2004 by SEC

Convert /' 4elationships $ *roblems

ot specific enough for the detailed modeling entities

e!g!

$ does not provide a wa of telling which of the man

possible sections a particular student is actuall enrolled in!

$ does not provide a wa of telling which of the man actualstudents are enrolled in a particular section!

STK+ETS SECTI1SE41YI




111/610

%%%

© 2004 by SEC

$ Solution

convert /' relationship into an intersection entit (orassociation entit)!

an /' relationship usuall represents a transaction that lin#s

the related entities! can be identified b as#ing Nwhat event or transaction cause the

/' relationship to occurO!

$ Intersection entit (association entit)

To represent a relationship about which we wish to maintainsome information!


S ti f t# ! + ti #i ( t’d)


112/610

%%2

© 2004 by SEC

3ohnMar!

Tania

ST6('#TS '#*O&&M'#T

ACC-.STA-.FI#-.FI#-/

S'CTIO#S

ST6('#TS

'#*O&&M'#T

S'CTIO#S

3ohn ACC-. 3ohn FI#-.

3ohn STA-.Mar! ACC-. Tania FI#-/

Se,antics of t#e !e+ations#i$s (cont’d)

EE! ode+ of #e Student Subsyste,


113/610

%%3

© 2004 by SEC

''*M ST6('#TS

'#*O&&M'#TS

*')IST*ATIO#S

P*O)*AMS

OFF'*I#)S

CO6*S'SS'CTIO#S

FAC6&T7

associationentities

M''TI#)S

characteristientities

S# ? EE! S1i++


114/610

%%4

© 2004 by SEC

o S#ar$en ?our EE! S1i++

3o"5(escription

Position Tas%s

Sta8 Manaement

Bene9ts

S%ills

'mplo!ees

Stoc%5Options

Pensions

S# ? EE! S1i++ ( t’d)


115/610

%%5

© 2004 by SEC

o S#ar$en ?our EE! S1i++ (cont’d)

"nswer the following 5uestions based on the EE4/ on the previous slide'

$ (0) +oes ever job description have a related positionM

$ (2) Can a tas# exist without a related job descriptionM

$ (3) Can a tas# be part of more than one job descriptionM

$ (6) Can a s#ill exist without a related tas#M

$ (7) Can an emploee be both staff and management at the same timeM

o S#ar$en ?o r EE! S1i++ (cont’d)


116/610

%%

© 2004 by SEC


$ (8) .ow man staff can a manager superviseM $ (9) hich emploees get both a pension and stoc# optionsM

$ (:) Can a manager get both pensions and stoc# optionsM

$ (


117/610

%%"

© 2004 by SEC


+raw EE4/ based on the statements below' $ (0) " countr has a capital cit!

$ (2) " dining philosopher is using a for#!

$ (3) " file is an ordinar file or a director file!

$ (6) >iles contain records!

$ (7) " polgon is composed of an ordered set of points!

$ (8) " drawing object is text, a geometrical object, or a group!



118/610

%%

© 2004 by SEC


$ (9) " person uses a computer language on a project! $ (:) /odems and #eboards are inputLoutput devises!

$ (


119/610

%%

© 2004 by SEC


"ppl E4+ and EE4/ to model the text description below! $ (a) " person has a name, address, and social securit number! " person

ma charge time to projects and earn a salar! " compan has a name,address, phone number, and primar product! " compan hires andfires persons! *erson and Compan have a man&to&man relationship!



120/610

%20

© 2004 by SEC


$ (b) There are two tpes of persons' wor#ers and managers! Eachwor#er wor#s on man projects% each manager is responsible for man projects! " project is staffed b man wor#ers and exactl onemanager! Each project has a name, budget, and internal priorit forsecuring resources!



121/610

%2%

© 2004 by SEC


$ (c) " compan is composed of multiple departments% each departmentwithin a compan is uni5uel identified b its name! " departmentusuall, but not alwas, has a manager! /ost managers manage adepartment% a few managers are not assigned to an department! Eachdepartment manufactures man products% while each product is made b exactl one department! " product has a name, cost, and weight!

Co,$onents of Structured &na+ysisprocess S*C processin( narrative


122/610

%22

© 2004 by SEC

process S*C processin( narrative

data > e?ternal entity !

process data ite. *% dia(ra.7data.odelin(8

!F! data store !ata !ictionary 7content8

uasicontinuous data flo@

control process

SA control ite.

control store

.ultiple instances of the sa.e process control ite.

CF! 7CS*C ,ar8 a reference to CS*C

control CS*C ST!

AT

Structured &na+ysis< d +i # i


123/610

%23

© 2004 by SEC

ode+ing ec#nique

model' describe information(data F control), flow, content! control&oriented applications deficienc

data&intensive applications

asic >otation


124/610

%24

© 2004 by SEC

asic >otation

+>+'

$ ' process (transformer of information) (I' dataLcontrolM)

(1'dataLcontrolM)

$ ' external entit (procedureLconsumer of information)

$ ' data item

$ ' data store (repositor of data observed b processes)

VV Control flow is not explicit!

VV The truth is that control is excluded in +>+ intentionall!

asic >otation (cont’d)


125/610

%25

© 2004 by SEC

asic >otation (cont d)

+>+ can be used to represent a sstem at an level of abstraction!(refine)

$ level =' context model (a single bubble)

$ information flow continuit' IL1 to each refinement must remain the same!

(balancing) o explicit indication of the se5uence of processing is supplied b

the +>+!

$ Explicit procedural representation delaed until design!



126/610

%2

© 2004 by SEC


Content of data (implied b the arrow or described b the store)

$ a collection of items' using data dictionar! (++) (onl content)

$ a need to represent the relationship between complex collections of data! (E&4 diagram for data modeling)



127/610

%2"

©

2004 by SEC

asic >otation (cont d)

processing narrative' describe (usuall natural language) a process bubble!

$ To specif the processing details in the bubble!

inputs to the bubble

algorithm applied to the input 1utput

4estrictions F limitations imposed on the process!

*erformance characteristics related to the process!

+esign constraints

E7tensions


128/610

%2

©

2004 by SEC

E7tensions

+ata&intensive application' $ +ata modeling to describe the relationshi# between complex

collections of data! (E&4 diagram)

Control&oriented application'

$ To describeLrepresent control flow and control processing as well asdata flow and processing!

E7tensions (cont’d)


129/610

%2

©

2004 by SEC

E7tensions (cont d)

(0)ard F /ellor extensions' extend S" notation!

$ ' 5uasicontinuous data flow (I'control L

1'control)

$ ' control process

$ ' control item

$ ' control store

$ ' process (multiple instances of the

same process)

E7tensions (cont’d)(2).atle and *irbhai Extensions' extend on representation of the control&oriented


130/610

%30

©

2004 by SEC

(2).atle and *irbhai Extensions' extend on representation of the control orientedaspects! (controlLevent)

$ otation'

' control flow (separate control flow diagram C>+ from +>+)

' reference to a control specification (CS*EC)

$ a window into an executive (CS*EC) that controls the processes in+>+ based on the event that is passed through the window!

$ CS*EC' (Control Specification)

& .ow the software behaves when a control signal is sensed!

& hich processes are invo#ed as a conse5uence of the occurrence ofthe controlLevent!

$ *S*EC' (*rocess Specification)

& To describe the inner wor#ings of a process representation!

E7tensions (cont’d) 4elation between data and control models


131/610

%3%

©

2004 by SEC

(F(s

PSP'Cs

Process

model

CF(s

CSP'C

Controlmodel

(ata output

(ata input

Processacti$ators

Controloutput

Controlinput

data conditions4occurs when data

input a process results in acontrol output

:: data conditions4a"o$e pressure

:: refer to CSP'C4in$o%e reduce tan

pressures

E7tensions (cont’d)


132/610

%32

©

2004 by SEC

CS*EC' if a data conditions occur which refers to aCS*EC bar, we must chec# CS*EC to determine whathappens when this event occurs!

$ *rocess activation table (*"T)' To indicate which processes areactivated b a given event that flows through the vertical bar!

$ State transition diagram (ST+)' To indicate how the sstem movesfrom state to state (behavior model)

state, an observable mode of behavior

events, cause the sstem to change state

8ata 8ictionary


133/610

%33

©

2004 by SEC

8ata 8ictionary

precise, rigorous definitions of all data elements pertinent tothe sstem!

usuall contain the following information'

$ ame, "lias, here usedL.ow used, Content description,

supplementar information!

$ Content description notation

R L L ? \ @ L Un L ( ) L composed ofand selection repetition option comments

recorded auto.atically fro.

the flo@ .odels

.unda,enta+ Issue


134/610

%34

© 2004 by SEC

.unda,enta+ Issue

data

control

data

control

Conventional

I' dataLcontrol

1' dataLcontrol

in +>+

ard&/ellor

IL1 data F control

IL1 control in +>+

.atle&*irbhai

IL1 data in +>+

IL1 control in +>+

S& and its E7tension


135/610

%35

© 2004 by SEC

S& and its E7tension

Summar'(0)Conventional'

ard&/ellor'

.atle&*irbhai'

process

process

CSP'C "ar

processcontrolprocess

control data item

data item

S& and its E7tension (cont’d)


136/610

%3

© 2004 by SEC

( )

(2)/odeling'

(0) information (control F data)flow and content &&& +>+ L C>+

(2) functionalit &&& data F process (+>+)

(3) behavior &&& CS*EC (ST+)


137/610

#e &na+ysis Process


138/610

%3

© 2004 by SEC

the problemthe problem requirementsrequirementselicitationelicitation


createcreate

analysisanalysismodelsmodels


e a ys s ocess


140/610

%40

© 2004 by SEC

g g

Software Syste,s

>unction1bject Dehavior

+ata >low

+iagram

Class

+iagram State Chart

Ste$s of &na+ysis< &n E7a,$+e:sing '' &$$roac#


141/610

%4%

© 2004 by SEC

+efine use cases Extract candidate classes

Establish basic class relationships

+efine a class hierarch

Identif attributes for each class

Specif methods that service the attributes

Indicate how classesLobjects are related

Duild a behavioral model

:sing '' &$$roac#

&$$+ication and So+ution 8o,ain


142/610

%42

© 2004 by SEC

$$

UML Package

"pplication +omain Solution +omain

"pplication +omain /odel Sstem /odel

&ircraft rafficContro++er

.+ig#tP+an &ir$ort

a$8is$+ay

.+ig#tP+an8atabase

Su,,ary8is$+ay

rafficContro+

rafficContro+

Conce$ts and P#eno,ena


143/610

%43

© 2004 by SEC

"henomenon -o)*ect.' "n object instance in the world of adomain,

$ E!g! / blac# watch

&once#t -o)*ect class.' +escribes the properties of phenomena

that are common, $ E!g! Dlac# watches

" concept is a 3&tuple'

$ Its /ame distinguishes it from other concepts!

$ Its "ur#ose are the properties that determine if a phenomenon is a memberof a concept!

$ Its Mem)ers are the phenomena which are part of the concept!

$

Conce$ts and P#eno,ena (cont’d)


144/610

%44

© 2004 by SEC

/odeling' +evelopment of abstractions to answer specific

5uestions about a set of phenomena while ignoring irrelevantdetails!

MembersName

Clock

Purpose

A device that

measures time.

C+ass


145/610

%45

© 2004 by SEC

C+ass

Class' $ "n abstraction in the context

$ encapsulates both state (variables) and behavior (methods)

$ Can be defined in terms of other classes using inheritance

Criteria of selecting classes

$ 4etained information

$ eeded services

$ /ultiple attributes

$ Common attributes

$ Essential re5uirements

C+ass Identification


146/610

%4

© 2004 by SEC

Identif the boundaries of the sstem $ hat object is inside, what object is outsideM

Identif the important entities in the sstem

$ earn about problem domain' 1bserve our client

$ Ta#e the flow of events and find participating objects in use cases(Scenarios and use cases)

$ "ppl design patterns

$ ouns are good candidates for classes

a$$ing Parts of S$eec# to'bect ode+ Co,$onents


147/610

%4"

© 2004 by SEC

'bect ode+ Co,$onents Part of speech

*roper noun

Improper noun

+oing verb

being verb

having verb

modal verb

adjective

transitive verb

intransitive verb

Model

component object

class

method

inheritance

aggregation

constraint

attribute

method

method (event)

Example

im Smith

To, doll

Du, recommend

is&a (#ind&of)

has an

must be

3 ears old

enter

depends

on

Cl

Pieces of an 'bect ode+


148/610

%4

© 2004 by SEC

Classes

"ssociations (4elations)

$ *art of& .ierarch ("ggregation)

$ -ind of&.ierarch (BeneraliHation)

"ttributes

$ "pplication specific

$ "ttributes in one subsstem can be classes in another subsstem, turningattributes to classes

Service

$ +omain /ethods' +namic model, >unctional model

$ Operation< " function or transformation applied to objects in a class! "ll objectsin a class share the same operations -Analysis "hase.

$ Signature: umber F tpes of arguments, tpe of result value! "ll methods of aclass have the same signature -+)*ect Design "hase.

$ Method < Implementation of an operation for a class -Im#lementation "hase., "olymor#hic o#eration' The same operation applies to man different classes!

'bect y$es


149/610

%4

© 2004 by SEC

Entit 1bjects' represent the persistent information ("pplicationdomain objects, NDusiness objectsO)

Doundar 1bjects' represent the interaction between the user and thesstem

Control 1bjects' represent the control tas#s performed b the sstem

Year

Month

Day

ChangeDateControl

LCDDisplayBoundary

ButtonBoundary

ode+ e#aior


150/610

%50

© 2004 by SEC

Indicate different states of the sstem Specif events that cause the sstem to change state

ode+ing E7a,$+e< & an1ingSyste,


151/610

%5%

© 2004 by SEC

Foo

Balance

CustomerId

Deposit()Withdraw()GetBalance()

C+ass Identification< >a,e of C+assA &ttributes and et#ods

>a,ing


152/610

%52

© 2004 by SEC

Foo

Balance

CustomerId


Account

Balance

CustomerId


“Dada”

Balance

CustomerId


.inding >ew 'bects


153/610

%53

© 2004 by SEC

Account

BalanceAccountId


Customer

Name

CustomerId

Iterate on Names, Attributes and Methods

Bank

Name

.inding >ew 'bects


154/610

%54

© 2004 by SEC

"ccount

Dalance

"ccountId

+eposit()ithdraw()

BetDalance()

Customer

ame

CustomerId

Dan#

ame

]Iterate on >a,esA &ttributes and et#ods].ind &ssociations between 'bects

]9abe+ t#e associations]8eter,ine t#e ,u+ti$+icity of t#e associations

.as

V

CategoriDe


155/610

%55

© 2004 by SEC

+onAt put too man classes into the same pac#age' 9&2 (or even 7&2)

/ortgage

"ccount

ithdraw()

*

"ccount

Dalance

"ccountId

+eposit()ithdraw()BetDalance()

Customer ame

CustomerId

Dan#

ame

.as

V

Saving

"ccount

ithdraw()

Chec#ing

"ccount

ithdraw()

#e &na+ysis Process


156/610

%5

© 2004 by SEC

the problemthe problem requirementsrequirementselicitationelicitation


createcreate

analysisanalysismodelsmodels



158/610

%5

© 2004 by SEC

data&intensive applications

'-* (iaram Semantic (ataModelin

OOA

OOP&

attributes relationship

aggregation

Service /essage between objects classification F inheritance


159/610

''& 8ata ode+ing (cont’d)


160/610

%0

© 2004 by SEC

+ata object attributes $ data object tables ' normaliHation result in minimum redundanc,

that is , the amount of information that we need to maintain tosatisf a particular problem is minimiHed!

ormaliHation rules(0) onl one value for each attribute

(2) attributes should contain no internal structure

Software &rtifacts Prob+e, state,ents


161/610

%%

© 2004 by SEC

$ to describe the problem to be solved and providing a conceptual overview of

the proposed sstem &na+ysis<

$ to understand and model the application and the domain (usuall called amodeling activit)

$ the output is a model capturing' functionalit, behavior, and structure 8esign<

$ +ata +esign'data abstraction%data structure%data modeling

$ *rocedural +esign' iteration , conditional, se5uence

$ "rchitectural +esign' program structure ( control hierarch )% sstemorganiHation ( software architecture )

I,$+e,entation<

$ Executable code

*#y 'bects-


162/610

%2

© 2004 by SEC

4eal&world objects v!s! software objects

$ communications

ro,le.

do.ain

Solution

do.ain

),ect necessary

for descri,in( a

solution % pro,le.

space

),ect reuired

for i.ple.entation

a solution % solutionspace

soft@are realiBation

of the real%@orld

pro,le.

'bect 'rientation


163/610

%3

© 2004 by SEC

Identit'

$ each object is a discrete and distinguishable entit!

$ each real&world object is uni5ue due to its existence!

$ each object has its own inherent identit, therefore, two objects aredistinct even if all their attribute values are identical!

Classification' $ objects with the same attributes and operations are grouped into a

class

$ each object is said to be an instance of its

class

$ e!g! Diccle object &&&&&&&X Diccle class

Attributes:

0rame sie

wheel sie 1perations:

shi0t

move

0 !11 ' 2 3onathan 4ee All 5ight 5eser$ed

'bect 'rientation (cont’d) * l hi


164/610

%4

© 2004 by SEC

*olmorphism'

$ the same operation ma behave differentl on different classes $ an operation is an action or transformation that an object performs or is

subject to

$ method' a specific implementation of an operation

a polmorphic operation is an operation that has more than onemethod implementing it!

Inheritance'

$ the sharing of attributes and operations among classes based on ahierarchical relationship

$ each subclass inherits all of the properties of its superclass and adds itsown uni5ue properties (called extension)

$ reusabilit

0 !11 ' 2 3onathan 4ee All 5i ht 5eser$ed

Po+y,or$#is, (#aing ,any for,s)


165/610

%5

© 2004 by SEC

Static polmorphism $ 1verloading' an invocation can be operated on arguments

of more than one tpe!

Class Time1f+a

public void setTime(char?:@ time) ^U%

public void setTme(int h, int m, int s) ^U%

U

Time1f+a aCloc#R new Time1f+a( )%

aCloc#!setTime(09,0,=)%

aCloc#!setTime(N00'77'==O)%

Po+y,or$#is,


166/610

%

© 2004 by SEC

+namic polmorphism' an object has more than one tpe $ object reference can refer to an instance of an of descendants of its class

$ an instance of the class created, and is also an instance of each that classAsancestors

$ the same operation ma behave differentl on different classes method' a specific implementation of an operation

a polmorphic operation is an operation that have more than onemethod implementing it!

Po+y,or$#is,< E7a,$+eclass Student extends *erson


167/610

%"

© 2004 by SEC

void getame() Sstem!out!println(NStudentO)% U

class Emploee extends *erson

void getame() Sstem!out!println(NEmploeeO)% U

U

public static void main(String ? @ args)

*erson p% Duffered4eader inRnew Duffered4eader(

new InputStream4eader(Sstem!in))%

int numRInteger!parseInt(in!readine())%

if (numR R0) p R new Emploee( )%

else p R new Student( )%

p!getame( )%

U


168/610


169/610

' et#odo+ogy (cont’d)


170/610

%"0

© 2004 by SEC

Three models'

$ object model' the static structures of objects F

their relationships

object diagrams' object classes (node), relationships

(arc)!

$ dnamic model' interactions(control) among objects

state diagrams' states(node), transitions(arc) b events

$ functional model' data transformation of objects data flow diagrams' processes(node), dataflows(arc)!

chane o$er time

asic Conce$ts

"bstraction' focus on the essential inherent aspects of entit


171/610

%"%

© 2004 by SEC

"bstraction' focus on the essential, inherent aspects of entit

and ignoring its accidental properties! $ e!g! Kse of abstraction during analsis' deciding onl with

application&domain concepts, not ma#ing design and implementationdecisions!

Encapsulation' (11) separate the external aspects of an

object, which are accessible to their objects, from the internalimplementation details of the object, which are hidden fromother objects!

Sharing through inheritance (4euse)

$ data structures and behaviors(design)

$ code

.eatures of 'bect 'rientation<+air’s Bersion

Identif


172/610

%"2

© 2004 by SEC

Identif

$ The uni5ue identification of ever object is through the use of anobject identifier!

Encapsulation

$ The selection of properties to be encapsulated!

attributes, operations, representations, algorithms!!! $ The determination of visibilit of these properties! (I!e! a well&

defined interface)

Classification' group associated objects according tocommon properties

$ The Intent of a classification is the description of that classificationcharacteristics, therefore, the intent specifies a predicate!

.eatures of 'bect 'rientation<+air’s Bersion (cont’d)

Th t d f l ifi ti i th t f bj t i th t i t


173/610

%"3

© 2004 by SEC

$ The extend of a classification is the set of objects in the current environmentwhich features such behavior, that is, a population selected b appling a predicate!

>lexible sharing' The abilit for an object to belong to more thanone classification! and will re5uire a flexible form of behaviorsharing!

$ are based on the encapsulated properties, the considered classificationscheme, the relationship between classifications!

Interpretation' The resolution of the precise semantics of theshared item of behavior!

$ two steps involved in the resolution' tpe chec#ing and binding! tping chec#ing' determination of whether operations are supported b

a particular object

binding' locate the correct implementation of the operation!

E7ercises


174/610

%"4

© 2004 by SEC

Doth S" and 11" offer the mechanism for the partition! +othe support the interactions between the different levelsM

Compare the similarit and differences between the datamodeling and object&oriented modeling!


175/610

C#a$ter 4Software 8esign


176/610

%"

© 2004 by SEC

6!0 +esign >undamentals

6!2 +esign /ethod

6!3 "rchitecture +esign

6!3!0 "rchitecture *atterns

6!6 +ata +esign

6!7 Interface +esign

6!8 *rocedural +esign


177/610


178/610

8esign .unda,enta+s (cont’d) >undamental Concepts


179/610

%"

© 2004 by SEC

p

$ "bstraction

procedural abstraction $ a named se5uence of instruction that has a specific function

data abstraction

$ a named collection of data

$ that describes a data object $ can refer all the data b stating the name of the data abstraction

$ original abstraction data tpe is used as a template or genericdata structure from which the data structure can be instructed!

9ee+ of abstraction=ig#est +ee+

/9ow +ee+

/9owest +ee+

9anguage usedProgra,6oriented ter,ino+ogy

/Procedura+6oriented ter,ino+ogy

/I,$+e,entation6oriented ter,ino+ogy

.unda,enta+ Conce$ts

$ 4efinement


180/610

%0

© 2004 by SEC

4efinement

Top&down design strateg " hierarch is developed b decomposing a statement of function ( a

procedural abstraction) in a stepwise fashion until programming statementsare reached

$ Ever refinement step implies some design decisions

" process elaboration $ Statement of function (description of information) without the internal

wor#ing of the function (internal structure of the information)

$ *roviding more and more details as each successible refinement occurs

.unda,enta+ Conce$ts (cont’d)

$ /odularit


181/610

%%

© 2004 by SEC

/odularit

/odules' software is divided into separatel named and addressablecomponents

/odules vs! interfaces between modules

$ "void overmodularit F undermodularit% notice that therelationship between modules (that is, the number of interfaces

increase expontentiall with the number of modules) $ Software architecture

.ierarch structure of procedural components

Structure of data

It relates elements of a software solution to parts of a real&world problem

.unda,enta+ Conce$ts (cont’d) $ Control hierarch (program structure)

The organiHation of program components F implies a hierarch of


182/610

%2

© 2004 by SEC

e o ga a o o p og a co po e s F p es a e a c ocontrol

$ +oes not represent procedural aspects of software (iteration,condition, se5uence)

+epth L width L fan&in L fan&out L superordinate L subordinate

Two characteristic of software architecture

$ isibilit' program components ma be invo#ed or used as data b given component (indirectl) (e!g! /6 is visible to /0)

$ Connectivit' program components are directl invo#ed or usedas data b given component (e!g! /2 is connected to /0)

" module that directl causes another module to begin

execution is connected to it/0 /2

/3 /6

.unda,enta+ Conce$ts (cont’d)

$ Software procedure focuses on the processing details of each module


183/610

%3

© 2004 by SEC

Software procedure focuses on the processing details of each moduleindividuall (se5uence, iteration, condition)

a procedural representation of software is laered

$ Information hiding

modules should be specified and designed so that information(procedure F data) contained within a module are inaccessible to

other modules that have no need for such information!

abstraction defines the procedural entities

hiding defines access constraints to both procedural detail within amodule and local data structure used b the modules

Effectie odu+ar 8esign

Effective modular design


184/610

%4

© 2004 by SEC

Effective modular design

$ " modular design reduces complexit, facilitates changes, results in aneasier implementation!

$ Classification (based on temporal aspect)

monolithicproram

moduleproram

o"ject-orientedproram

code-and-9?

se5uential L incremental L parallel

subroutines L coroutines L conroutines

ithout apparentinterruption

L Can beinterrupted beforecompletion

L executesimultaneousl withanother module

Effectie odu+ar 8esign (cont’d)

$ " tpical control hierarch ma not be encountered when coroutines or


185/610

%5

© 2004 by SEC

" tpical control hierarch ma not be encountered when coroutines orconroutines are used

$ >unctional independence (independent effective modules)

Effective modularit' function compartmentaliHed and interfacessimplified

$ Cohesion' relative functional strength of a module

coincidental ' tas#s relate to each other loosel logical ' performing tas#s related logicall ( all output )

temporal ' all tas#s executed with the same span of time

procedural ' must be executed in a specific order

communicational ' concentrate on one area of a data structure se5uential

functionalhih

low

Effectie odu+ar 8esign (cont’d)

$ Coupling' interconnection among modules


186/610

%

© 2004 by SEC

Coupling' interconnection among modules

depends on the interface complexit between modules, entit pointor reference to a module, what data passes across the interface

o direct coupling ' module subordinate to different modules +ata coupling ' data passed via argument list Stamp coupling ' data structure passed via argument list control coupling ' passes control data external coupling ' modules are tied to an external environment common coupling ' refer to a global data area content coupling '

$ one module ma#es use of data or control informationmaintained within the boundar of another module !

$ branches are made into the middle of a module

hih

low

middle

8ata 8esign$ +efine data abstractions

data a"straction


187/610

%"

© 2004 by SEC

+efine data abstractions

$ Select an appropriate data structure to implement the abstraction $ Ksing entit&relationship modeling depict relationship between

objects

data a"straction

data structure

data modelin


188/610

&rc#itectura+ 8esign (cont’d)

aered sstems'


189/610

%

© 2004 by SEC

ae ed ss e s'

$ Sstem organiHed hierarchicall with each laer providingservice to the laer about it

4ule&based sstem

Dlac#board sstems' a central data structure represents the currentstate of the computation, a collection of #nowledge sources!

S!stem

Basic

Core

,nowlede Base

*B Fact

*ule 2 dataelement

*uleinterpreter

or%in

Memor!Input

Output selected

rulesdata

Blac%"oard

Procedura+ 8esign Structure programming


190/610

%0

© 2004 by SEC

Structure programming

$ logical constructs' se5uence, conditional, iteration $ to limit the procedural design to a small number of predictable

operations

reduce program complexit

lead to more readable, testable code

>low charts

$ Braphical representation for procedural design

$ imitation

Introduce inefficienc when an escape from a set of nested loopsor nested conditions is re5uired

"dditional complications of logical tests

Procedura+ 8esign (cont’d)

*rogram design language (*+)


191/610

%%

Slides of Software Engineering Consortium

Documents

Transcript of Slides of Software Engineering Consortium