software engineering - PowerPoint PPT Presentation

About This Presentation
Title:

software engineering

Description:

it describe software engineering. – PowerPoint PPT presentation

Number of Views:121
Learn more at: http://www.powershow.com
Slides: 612
Provided by: sanakhan143
Category:
Tags:

less

Transcript and Presenter's Notes

Title: software engineering


1
Introduction to Software Engineering
  • Software Engineering Consortium
  • (SEC)

2
Preface and Introduction (contd)
  • The objective of this course is to explain the
    Introduction of software engineering , and
    provide an easy and practical introduction to the
    important characteristics of software
    engineering. After taking this course, students
    will understand
  • what is software engineering
  • why software engineering is important
  • how to develop software and manage a software
    project by using the software engineering in
    detail.

3
Preface and Introduction (contd)
  • This courseware is designed for a semester-long
    for junior or senior undergraduate students, and
    for the industrial parties. The following
    professors contribute to the development of this
    courseware
  • Jonathan Lee, PhD. (???)
  • Chung-Shyan Liu, PhD. (???)
  • J.-Y. Kuo, PhD. (???)
  • Chien-Hung Liu, PhD. (???)
  • The Minister of Education sponsors this
    courseware development.

4
Prerequisites
  • Introduction to Computer Science
  • Programming Skills

5
Contents
  • Chapter 1. An Overview of Software Engineering
  • Chapter 2. Software Processes
  • Chapter 3. Requirements Engineering
  • Chapter 4. Software Design
  • Chapter 5. Object-Oriented Software Development
  • Chapter 6. Software Testing
  • Chapter 7. Software Project Management and
    Planning
  • Chapter 8. Software Quality Assurance
  • Chapter 9. Software Maintenance
  • Chapter 10. Formal Methods and Software
    Engineering
  • Chapter 11. Advanced Topics in Software
    Engineering

6
References
  • Pressman 2004 Roger S. Pressman. Software
    Engineering a practitioners approach, 6th
    edition. McGRAW-HILL.
  • Sommerville 2004 Ian Sommerville. Software
    Engineering, 7th edition. Addison Wesley.
  • Rumbaugh et al.1991 J. Rumbaugh, M. Blaha, W.
    Premeerlani, F. Eddy, and W. Lorensen.
    Object-Oriented Modeling and Design. PRENTICE
    HALL, 1991.
  • DIL1994 A. Diller. Z An Introduction to Formal
    Methods, 2nd Edition. John Wiley Sons, 1994
  • WOO88 J. Woodcock and M. Loomes. Software
    Engineering Mathematics Formal Methods
    Demystified. Pitman Publishing. 1988
  • WOR92 J.B. Wordsworth. Software Development
    with Z A Practical Approach to Formal Methods in
    Software Engineering. Addision-Welsey Publishing
    Company. 1992

7
References (contd)
  • Beizer 1990 B. Beizer, Software Testing
    Techniques, 2nd Edition, Van Nostrand-Reinhold,
    1990.
  • Boehm 1981 B. Boehm, Software Engineering
    Economics, Prentice-Hall, 1981.
  • Davis 1995 A. Davis, 201 Principles of Software
    Development, McGraw-Hill, 1995.
  • Gao 2003 Jerry Gao, Jacob Tsao, and Ye Wu,
    Testing and Quality Assurance for Component-Based
    Software, Artech House, 2003.
  • Kaner 1993 C. Kaner, J. Falk, and H. Q. Nguyen,
    Testing Computer Software, 2nd Edition, Van
    Nostrand-Reinhold, 1993.
  • Myers 1979 G. Myers, The Art of Software
    Testing, Wiley, 1979.

8
Chapter 1 An Overview of Software Engineering
9
Chapter 1 An Overview of Software Engineering
  • 1.1 Software Crisis
  • 1.2 Software Myths
  • 1.3 Software Engineering Paradigm
  • 1.4 The Evolution of Software Engineering
  • 1.5 Software Engineering in Taiwan

10
What is the Problem?
  • 84 of all software projects do not finish on
    time and within budget (Survey conducted by
    Standish Group)
  • 8000 projects in US in 1995
  • More than 3o of all projects were cancelled
  • 189 over budget
  • Key issues
  • Software firms are always pressured to perform
    under unrealistic deadlines.
  • The clients ask for new features, just before the
    end of the project, and unclear requirements.
  • Software itself is awfully complex.
  • Uncertainties throughout the development project.

11
Real Cases
  • Bank of America Master Net System
  • Trust business. 1982.
  • Spend 18 months in deep research analysis of
    the target system.
  • Original budget 20 million.
  • Original Schedule 9 months, due on 1984/12/31.
  • Not until March-1987, and spent 60 million.
  • Lost 600 millions business
  • Eventually, gave up the software system and 34
    billion trust accounts transferred.
  • Other cases
  • Explosion of Ariane 5 prototype in 1996
  • Explosion of Boeings Delta III rocket.

12
Problems of Software
  • General issues
  • HW vs. SW
  • Productivity build new programs from scratch
  • Maintenance maintain existing programs
  • Essence vs Accidental (F. Brooks)

13
F. Brooks Essence
  • Essence the difficulties inherent in the nature
    of software
  • Complexity development process, application
    domain, internals of the system (e.g., number of
    states, size of software, functionality,
    structures, and behaviors).
  • Conformity software must adapt to interact with
    people according to their diverse needs
    therefore, software cannot be completely
    represented formally.
  • Changeability software component is usually the
    easiest one to modify (application changes,
    software changes).
  • Invisibility software structure is hidden, only
    behavior can be observed when executing the
    software.

14
F. Brooks Accidents
  • Accident difficulties arise in representing,
    testing the conceptual constructs (SW) (e.g.,
    software development process), examples of
    accidental difficulties
  • accidental complexity abstract program vs
    concrete machine program solved by HLL.
  • slow turnaround batch programming vs
    time-sharing (shortest response time) solved by
    time-sharing.
  • no standard formats individual programs vs
    integrated library, standard formats solved by
    unified programming environment.

15
Characteristics of Software
16
Software Myths (contd)
  • Management Myths
  • We already have a book thats full of standards
    and procedures for building software. Wont that
    provide my people with everything they need to
    know?
  • My people do have state-of-the-art software
    development tools after all, we buy them the
    newest computers
  • If we get behind schedule, we can add more
    programmers and catch up

17
Software Myths (contd)
  • Customer Myths
  • A general statement of objectives is sufficient
    to begin writing programs we can fill in the
    details later
  • Project requirements continually change, but
    change can be easily accommodated because
    software is flexible

18
Software Myths (contd)
  • Practitioners Myths
  • Once we write the program and get it to work, our
    job is done
  • Until I get the program running I really have
    no way of assessing its quality
  • The only deliverable for a successful project is
    the working program

19
What is Software Engineering?
Software Engineering
Real World
Software World
20
Software Engineering Paradigm
  • Software engineering is a discipline that
    integrates methods, tools, and procedures for the
    development of computer software.
  • Method introduce a way to build SW
  • Tool automatic, semi-auto support for methods
  • Procedure define the sequence in which methods
    will be applied, the controls that help ensure
    quality and coordinate changes.

21
Software Process
  • Waterfall life cycle
  • Prototyping
  • Spiral model
  • Automatic synthesis model
  • Object-oriented model
  • 4 GL model

22
Traditional Software Engineering
Software Systems
Function
Behavior
Data
Entity-Relation Diagram
Data Flow Diagram
State Transition Diagram
23
Object-Oriented Software Engineering
Software Systems
Object
Behavior
Function
Data Flow Diagram
Class Diagram
State Chart
24
Software Industry
  • Independent Programming Service
  • Software Product
  • Enterprise Solution
  • Packaged Software for the Mass
  • Internet Software and Services

25
Independent Programming Services (Era 1)
  • Feb 1955, Elmer Kubie and John Sheldon founded
    CUC
  • the First Software Company that devoted to the
    construction of software especially for hardware
    company.
  • Promoting Software Industry two Major Projects,
  • SABRE, airline reservation system, 30 million.
  • SAGE, air defense system (19491962)
  • 700/1000 programmers in the US. 8 billion.

26
Software Product (Era 2)
  • 1964 Martin Goetz developed Flowchart Software --
    Autoflow for RCA, but rejected.
  • Sale to the customer of RCA IBM.
  • Develop and market software products not
    specifically designed for a particular hardware
    platform.
  • MARK IV, a pre-runner for the database management
    system.
  • IBM unbundled software from hardware.

27
Enterprise Solutions (Era 3)
  • Dietmar Hopp. IBM Germany
  • Systems, Applications and Products (SAP)
    3.3billion (1997)
  • Setting up shop in Walldorf, Germany.
  • Marked by the emergence of enterprise solutions
    providers.
  • e.g. Baan 1978. Netherlands. 680 million
    (1997)
  • Oracle 1977. U.S.
  • Larry Ellison.
  • ERP, 45 billion (1997)

28
Packaged Software for the Masses (Era 4)
  • Software products for the masses. 1979.
  • VisiCalc, Spreadsheet program.
  • August 1981 The deal of the century.
  • Bill Gates bought the first version of the OS
    from a small firm called Seattle Computer
    Products for 50,000 without telling them it was
    for IBM.
  • The development of the IBM PC, 1981, initiated a
    4th software era.
  • PC-based mass-market software. Few additional
    services are required for installation.
  • Microsoft reached revenues of 11.6 billion.
    Packaged Software Products, 57 billion (1997)

29
Internet Software and Services (Era 5)
  • Internet and value-added services period, 1994. W
  • with Netscapes browser software for the internet.

30
IT Market
Hardware products
Hardware maintenance
Software Products Services
Processing Services and Internet Services
Embedded Software
Professional Service
Software Products
Enterprise Solution
Packaged Mass-Market Software
31
Software Products and Services
Enterprise Solutions IBM Oracle Computer
Associates SAP HP Fujitsu Hitachi Parametric
Technology People Soft Siemens
Packaged Mars-Market Software Microsoft IBM Comp
uter Associates Adobe Novell Symantec Intuit Autod
esk Apple The Learning Company
Professional Software Services Anderson
Consulting IBM EDS CSC Science Applications Cap
Gemini Hp DEC Fujitsu BSO Origin
32
Exercises
  • Please find the definition of Software
    Engineering from the text books, papers, and
    Internet as many as possible.
  • Please survey the software engineering
    application in industries of TAIWAN.

33
Chapter 2 Software Process Model
34
Chapter 2 Software Process Model
  • 2.1 Introduction to Software Process
  • 2.2 Software Life Cycle
  • 2.2.1 Waterfall Model
  • 2.2.2 Prototyping
  • 2.2.3 Incremental Model
  • 2.2.4 Spiral Model
  • 2.2.5 Fourth-Generation Techniques
  • 2.2.6 Unify Process Model
  • 2.2.7 Automatic Software Synthesis

35
Chapter 2 Software Process Model (contd)
  • 2.3 Generic View of Software Engineering
  • 2.4 Comparison of Software Development Processes
  • 2.5 Advanced Topics
  • 2.5.1 CMM/CMMI
  • 2.5.2 Model Driven Development
  • 2.5.3 Extreme Programming
  • 2.5.4 Agile Method
  • Exercises

36
Introduction to Software Process
  • Requirement acquisition (problem statements)
  • to describe the problem to be solved and
    providing a conceptual overview of the proposed
    system
  • Requirement analysis
  • Requirement specification
  • System analysis
  • System design

37
Introduction to Software Process (contd)
  • Detail design
  • Coding
  • Testing
  • Maintenance

38
Requirement Analysis
  • A process of discovering, refinement, modeling
    and specification.
  • Principles represent information domain of a
    problem
  • information flow data control changes
  • information content composite term.
  • information structure organization
  • Modeling (graphical textual description)
  • modeling methods SA, OOA, JSD, DSSD, SADT
  • model component information, function, behavior

39
Requirement Analysis (contd)
  • Artifact
  • Requirement specification.
  • capturing functionality, behavior, and structure

40
Design
  • The problem is decomposed into modules
  • The interface between modules must be specified
  • Define architecture
  • Artifact design model
  • Data design
  • data abstraction, data structure, data modeling
  • Procedural design iteration , conditional,
    sequence
  • Architectural design program structure, software
    architecture)

41
Implementation
  • Individual module programming
  • Pseudo-code
  • The goals
  • the development of a well-documented
  • The reliable, easy to read, flexible, correct
    program
  • Integration of modules
  • Artifact executable program

42
Testing
  • Test the system from requirement engineering to
    implementation
  • Verification and validation
  • Artifact testing report

43
Maintenance
  • Maintain the user satisfaction
  • Repair errors, requirements changed or extended
  • Changes in both the systems environment and user
    requirements are inevitable
  • Maintenance Evolution

44
Maintenance (contd)
  • Kinds of maintenance activities
  • Corrective
  • Adaptive
  • Perfective
  • Preventive

45
Software Life Cycle
  • Waterfall model
  • Prototyping
  • Incremental model
  • Spiral model
  • Fourth-generation techniques
  • Unify process model
  • Automatic software synthesis

46
Waterfall Model
  • Frequently implemented based on a view of the
    world interpreted in terms of a functional
    decomposition.
  • What does the system do?
  • Based on functional decomposition.
  • top-down analysis and design methodology
  • SA/SD
  • based on data flows DFD, DD, structure charts.
  • easily to map to conventional procedural language

47
Waterfall Model (contd)
User Requirements Analysis
ANALYSIS
User Requirements Specification
WHAT
Software Requirements Specification
System/Board Design Logical Design
DESIGN
HOW
Program/Detailed Design Physical Design
implementation/Coding
Program Testing Units
Program Testing system
BUILD
Program Use
software Maintenance
48
Prototyping Model
  • Throwaway implement only aspects poorly
    understood.
  • Evolutionary more likely to implement best
    understood benefits
  • improve communication
  • reduce risk
  • most feasible way to validate specification
  • for maintenance as well.

49
Prototyping Model (contd)
  • The roles of prototyping
  • as a means to acquire validate users
    requirements.
  • as scaled-down version of the final operational
    system.
  • as a means to validate solution specifications.
  • as a solution specification for design and
    implementation

50
Prototyping Model (contd)
51
Spiral Model
  • Spiral model
  • Risk driven
  • Throwaway prototyping

52
Spiral Model (contd)
Progress through steps
Cumulative cost
Evaluate alternatives identify, resolve risks
Determine objectives, alternative, constraints
Risk analysis
Risk analysis
Risk analysis
Risk analy -sis
Operational Prototype
Prototype
Prototype
Prototype
Commitment partition
1
2
3
Simulations, models, benchmarks
Requirements plan life-cycle plan
Review
Software requirement
Detailed design
Software product design
Requirement validation
Development plan
Plan next phases
Code
Unit test
Design validation and verification
Integration and test plan
Integration and test
Acceptance test
Implemen- tation
Develop, verify next-level product
53
Automated Synthesis Model
54
Fourth-generation Techniques
55
Object-Oriented Approach
  • OOA emphasizes on finding and describing the
    objects - or concepts - problem domain.
  • OOD emphasizes on defining logical software
    object that will ultimately be implemented in an
    object-oriented programming language.
  • OOP (Programming), implements the designed
    components in C, Java.

56
Object-Oriented Approach (contd)
Public class Boat public void sail()
private Date age
Boat
age
OOA
OOD
OOP
Add detail and design decisions
Develop model of requirements
Develop code
Users Perspective
Developers Perspective
57
Object-Oriented Approach (contd)
Maintenance
Further Development
Program Use
System Testing
  • bottom-up develop an individual class
  • top-down analysis

Unit Testing
Coding
Program Design
System Design
Software Requirements Specification
User Requirements Specification
Requirements Analysis
58
Generic View of Software Engineering
  • Definition What
  • Development How
  • Maintenance Change

59
Comparing Various Models
  • Waterfall model problems
  • traceability/languages in different phases
  • Process is too linear
  • requirement acquisition and validation
  • maintainability due to the use of functional
    decomposition
  • assume fully elaborated documentation at the
    early stage of the life cycle.
  • reusability top-down design
  • communication

60
Comparing Various Models (contd)
  • based on functional decomposition
  • Strongly dependent on detailed functional
    breakdown
  • not consider evolutionary changes.
  • not encourage reusability
  • Prototyping (partial implementation )
  • Benefits
  • improve communication

61
Comparing Various Models (contd)
  • reduce risk
  • communication between developments
  • determine a proposed designs unknown properties
  • address requirement acquisition and validation
    limitation
  • provide a basis for assessing the feasibility and
    performance of alternative designs
  • most feasible way to validate specification.
  • for maintenance as well
  • Limitation
  • quick and direct approach without considering
    issues such as quality and maintainability.

62
Comparing Various Models (contd)
containing quantifies
supporting formal reasoning
detail algorithm and data structure
verify correctness and completeness of design or
implementation
executable
low priority
prototyping lang.
no
yes
no
must
yes
interconnections during architecture and module
design
specification language
not necessary
no
not
Design language
no
programming language
efficient
  • Language

63
Comparing Various Models (contd)
E
Functionality
inappropriateness
D
shortfall
B
C
lateness
slop adaptability
original reqt.
longevity
A
Time
t0
t1
t2
t3
t4
t5
O (t0) original reqt. A ( at t1) an
operational product, not satisfying the old to
needs because poor understanding of
needs. A - B undergo a series of
enhancements. B - D the cost of enhancements
increase, to build a new system. stop at t4.
cycle repeat itself
waterfall model
64
Throwaway Prototyping and Spiral Model
before understanding of the users need gt
increase in functionality
Functionality
t0
t1
t2
t4
Time
65
Evolutionary Prototyping
66
Automated Software Synthesis
67
Reusable Software versus Conventional
conventional approach
68
Exercise
  • Do you think complexityand changeis the
    problems of software development? Why?
  • Comparison of different software engineering
    paradigms
  • waterfall, prototyping, spiral, OOLC, 4GL
  • prototype both specification and design
  • program optimization

69
Exercise (contd)
  • Issues in using different kinds of language in
    waterfall model
  • different phases need different kinds of
    languages
  • transformation between languages at different
    phases.
  • main features of each language
  • specification, design, prototype, program
  • specification abstract of system functionality
  • design abstract of system structure
  • prototype both specification and design
  • program optimization

70
Chapter 3 Requirements Engineering
71
Chapter 3 Requirements Engineering
  • 3.1 Requirements engineering
  • 3.1.1 Software requirements
  • 3.1.2 Characteristics of requirements
  • 3.1.3 Requirements engineering
  • 3.1.4 Requirements elicitation
  • 3.2 Requirements analysis
  • 3.2.1 Software modeling
  • 3.2.2 The analysis process
  • 3.2.3 Entity-Relationship diagram (ERD)
  • 3.2.4 Extended entity-relationship diagram
    (EERD)
  • 3.2.5 Components of structured analysis

72
Chapter 3 Requirements Engineering (contd)
  • 3.3 Object-oriented (OO) software engineering
  • 3.3.1 Steps of analysis an example using OO
    approach
  • 3.3.2 Concepts and phenomena
  • 3.3.3 Class and class identification
  • 3.3.4 Pieces of an object model
  • 3.4 Data modeling and OOA
  • 3.4.1 Data modeling and OOA
  • 3.4.2 Software artifacts
  • 3.4.3 Object Orientation
  • 3.4.4 Polymorphism
  • 3.4.5 OMT methodology
  • 3.4.6 Features of object orientation Blairs
    version

73
3.1 Requirements Engineering
74
Software Requirements
  • Requirement
  • Functional requirement describes system services
    or functions
  • Non-functional requirement is a constraint or a
    goal on the system or on the development process
  • User (Customer) requirement
  • A statement in natural language plus diagrams of
    the services the system provides and its
    operational constraints
  • Requirements specification
  • A structured document for detail description of
    the system services.
  • Written as a contract between client and developer

75
Characteristics of Requirements
  • Incomplete Requirements
  • Most software systems are complex, that developer
    can never fully captured during the system
    development, therefore, requirements are always
    incomplete.
  • Inconsistent Requirement
  • Different users have different requirements and
    priorities. There is a constantly shifting
    compromise in the requirements.
  • Prototyping is often required to clarify
    requirements.

76
Requirements Engineering
  • Requirements elicitation
  • Determine what the customer requires
  • Requirements analysis
  • Understand the relationships among various
    customer requirements
  • Requirements negotiation
  • Shape the relationships among various customer
    requirements to achieve a successful result
  • Research on requirements trade-off analysis
    (formulating as goals)
  • Requirements specification
  • Build a form of requirements

77
Requirements Engineering (contd)
  • Software modeling
  • Build a representation of requirements that can
    be assessed for correctness, completeness and
    consistency.
  • Requirements validation
  • Review the model
  • Requirements management
  • Identify, control and track requirements and the
    changes.

78
Requirements Elicitation
  • Two sources of information for the requirements
    elicitation process
  • User (customer)
  • Application domain
  • Asking
  • Ask users what they expect from the system
  • Interview, brainstorm and questionnaire
  • Task analysis
  • High-level tasks can be decomposed into sub-tasks
  • Scenario-based analysis
  • Study instances of tasks
  • A scenario can be real or artificial

79
Requirements Elicitation (contd)
  • Form analysis
  • A lot of information about the domain can be
    found in various forms (examples in ERD slides)
  • Forms provide us with information about the data
    objects of the domain, their properties, and
    their interrelations
  • Natural language description
  • with background information to be used in
    conjunction with other elicitation techniques
    such as interviews
  • Derivation from an existing system
  • Take the peculiar circumstances of the present
    situation into account (examples in ERD slides)
  • Prototyping

80
3.2 Requirements Analysis
81
Requirement Analysis
  • Information domain analysis
  • information flow data transformation
  • data content data dictionary
  • data modeling
  • Functional and behavioral representation
  • function process transformation
  • behavior state transition diagram
  • Interfaces definition
  • function/process interface
  • Problem partition and abstraction
  • at different levels of abstraction
  • classification and assembly structure

82
Software Modeling
  • Purpose
  • focus on those qualities of an entity that are
    relevant to the solution of an application
    problem
  • abstract away those that are irrelevant
  • Model an abstraction for
  • Understanding before (actually) building
  • Communication
  • Visualization
  • Reducing complexity
  • Methodology build (analyze) a model of an
    application domain

83
Application and Solution Domain
  • Application Domain (Requirements Analysis)
  • The environment in which the system is operating
  • Solution Domain (System Design, Object Design)
  • The available technologies to build the system

84
The Analysis Process
build a prototype
requirements elicitation
develop Specification
the problem
Review
create analysis models
85
Traditional Software Engineering
Software Systems
Function
Behavior
Data
Entity-Relation Diagram
Data Flow Diagram
State Transition Diagram
86
From Analysis to Design A Traditional Approach
ERD
DFD
Structured chart
Database
Tables
Structured
Screen Report
English
87
Entity-Relationship Diagram
  • Entity
  • Primary things an organization collects and
    records information about. (noun) ( )
  • E.g. persons, products, places, etc.
  • Relationship
  • Linkage between entities. (verb) ( )
  • E.g. Persons perform jobs, Jobs consist-of tasks
  • Cardinality
  • Identify how many instances of one entity are
    related to how many instances of another entity.

88
Entity-Relationship Diagram (contd)
  • Direction
  • using an arrow pointing to the object of the
    action.
  • Examples

Persons
MN
11
Persons
1N
Jobs
serve
perform
consist_of
Jobs
Customers
Tasks
Serve
Persons
Customers
Perform
Consist-of
Tasks
Jobs
89
Entity-Relationship Diagram (contd)
Assist

Faculty
Students
Advice
Take
Teach
Courses
  • Attributes Properties to describe an entity
  • key attribute (key, identifier) to characterize
    the specific entity (to retrieve a single entity
    occurrence (instance))
  • unique to ensure that no other record has the
    same identifier.
  • unchanging to ensure that it always refers to
    the same thing.

90
Entity-Relationship Diagram (contd)
  • Student is an entity about which a university
    stores info such as the Student_id, name, and
    phone.
  • Compound keys made up of a number of different
    subkeys to produce a unique identifier
  • e.g. course number section number term
  • The difference between an entity and an attribute
    is that attributes are atomic.
  • i.e. Attributes have no further attributes that
    describe them. Entities can be further described
    by their attributes.

Entity type
Key attribute
Attribute
e.g.
actual data
Students Student_id
name
phone
50416938 Doakes,, Jane
242-7147 71426006 Blough, JO
426-4141
Entity occurrence
91
Advanced Features
  • Kernel and characteristic entities
  • Entities can be described by other subsidiary
    entities in a hierarchical fashion.
  • to store related values of one of the attributes
    of an entity.

Entities
Keys
Attributes
name credits
Courses
Course_id
Course_id Section_id
Faculty
Sections
Meeting_day Meeting_time Room
Course_id Section_id Meeting_id
Meetings
92
Advanced Features (contd)
  • The highest entity type in the hierarchy is
    called a kernel entity, which has a unique
    identity that does not depend on the existence of
    any other entity type.
  • Characteristic entities to record the repeated
    characteristics of the kernel entity.
  • e.g. Course is a kernel entity, Sections and
    Meetings are characteristic entities describing
    the characteristics of Courses.
  • The unique identifier for the characteristic
    entities is a multiple key.
  • e.g. Course_id Section_id are needed to
    uniquely identify a section.

93
Advanced Features (contd)
  • Recursive relationships an entity is related to
    itself
  • e.g.
  • for retrieving all family relationships

Is_Parent_of
Is_Married_To
Person
Is_Child_of
94
Advanced Features (contd)
  • N-ary relationships
  • e.g.
  • An example

Teach
Take
Courses
Faculty
Students
Occupy
Contain
Sections
Rooms
Have
Meetings
95
Where to look for information?
  • existing forms
  • forms organize the data and remind what to
    collect.
  • It is common in manual systems to provide large
    amounts of redundant data.
  • e.g. Scholarship Application Form

Scholarships
Student number _____ name ________ Year of
program ____ GPA ___
Receive
Apply for
Students
names of Scholarship applied for
request
Reference Letters Requested form (names and
addresses)
Referees
96
  • Existing file structures
  • Frequently organizations have a collection of
    application programs that do not link to each
    other. They may require complex programs to
    transform data used by one application into a
    form used by another one.
  • e.g. existing student record system

Accounts Account_id, Label Buildings
Building_id, Name, Address. Courses Course_id,
Course_Name, Credits. Course_Program Course_id,
Program_id Departments Department_id,
Department_Name. Enrolled Student_id, Course_id,
Section_id, Year, Term, Grade. Faculty
Faculty_id, Name, Address, Birthday. Fee_Payments
Student_id, Account_id. Prerequisites
Course_id, Pre1, Pre2, Pre3. Programs
Program_id, Program_Name. Rooms Building_id,
Room_id, Size, Type. Sections Course_id,
Section_id, Year, Term, Faculty_id (Meeting_id,
Building_id, Room_id, Day, Time) ... Students
Student_id, Name, Address, Birthday.
97
  • Kernel entities single keys, such as Accounts,
    Buildings, Courses, Departments, Faculty,
    Prerequisites, Programs, and Students
  • Characteristic entity vs. Relationship (rules)
  • kernel entity (or characteristic entity)s key
    not part of the key of any entity
  • gt characteristic entity
  • multiple keys are combinations of keys for other
    entities gt MN relationships
  • e.g Course_program course_id, program_id...
  • Enrolled students_id, course_id,...
  • e.g Rooms building_id lt---- from buildings
  • room_id lt--- not identified precisely
  • characteristic entity

98
ERD from Existing Forms and Files
Buildings
Accounts
Referees
fee-payment
applied-for
Scholarships
Rooms
Students
receive
Meetings
Sections
Courses
course-program
Faculty
Departments
Programs
99
Testing ERD
  • No identification key for entity
  • Two or more entities have the same key
  • Many relationships to a single entity
  • Two or more relationships between the same
    entities
  • N-ary relationship
  • An entity has no relationship

100
Extended Entity-Relationship Model
  • To define the logical content of the database
  • Extension in two dimensions
  • to document the attribute of each entity
  • to document the semantic meaning of the
    relationships

101
Define Attributes
  • Attributes an elementary item of recordable data
    that cannot be further subdivided into meaningful
    data items. (Field or descriptor)
  • 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 any single entity occurrence.
  • If there is more than one value for the same
    entity occurrence, a new characteristic entity
    must be created to contain the multiple values.

102
Define Attributes (contd)
  • Primary key to identify uniquely each occurrence
    of an entity, with the following properties
  • unique
  • unchanging
  • never has a null or missing value
  • can have more than one attribute to create a
    unique key.
  • a single attribute an atomic key.
  • multiple attributes a compound key.
  • dataless keys are not subject to change in the
    way that keys made up of data items often do.
  • Alternate key to provide a choice of identifiers.

103
Define Attributes (contd)
  • Foreign key to create a link with another
    entity, e.g. PROGRAM_ID is a foreign key linking
    STUDENTS to PROGRAMS.
  • Null OK to indicate whether this attribute can
    ever have a null value.
  • if an attribute does not exist for some
    occurrences of an entity.
  • if it exists but is not know at the time the
    entity occurrence is recorded.
  • foreign key can have a null value if the
    relationship that they map is optional.
  • Type types of attributes.
  • Width max number of characters or digits.

104
Define Attributes (contd)
  • Example

Entity STUDENTS
ATTRIBUTE
PRIMARY KEY
FOREIGN KEY
NULL OK
TYPE
WIDTH
ID
X
9
STUDENT_ID
SURNAME
CHAR
20
FIRSTNAME
CHAR
20
PROGRAM_ID
X
ID
9
105
Semantics of the Relationships
  • Relationships
  • Extension to allow for
  • optionality to determine whether the linked
    entities must always be linked.
  • existence dependency to determine whether the
    existence of an entity occurrence depends on the
    existence of an occurrence of anther entity.
  • abstractions permit the definition of a
    hierarchy of entities with rules about how the
    levels of the hierarchy are related.

106
Semantics of the Relationships (contd)
  • Optionality
  • Mandatory If the relationship between entities A
    and B is mandatory, then each instance of A must
    correspond to an instance of B
  • Optional If it is optional at the end of A, then
    some instance of A can be recorded that has no
    relationship to any instance of B
  • e.g.

107
Semantics of the Relationships (contd)
  • Existence Dependency
  • to describe the relationship between
    characteristic entities and kernel entities

Courses optionally have one or
more sections
HAVE
COURSE
SECTIONS
Courses must have one of
sections
HAVE
COURSE
SECTIONS
108
Semantics of the Relationships (contd)
  • Abstractions
  • the more specific entities inherit the properties
    of the more abstract entities
  • specific entities are collected into subtypes
    that share common properties with the more
    general entity, called a supertype
  • overlapping subtypes (or aggregation
    relationship)
  • IS-PART-OF ( )
  • e.g.
  • optional

109
Semantics of the Relationships (contd)
  • Mutually exclusive subtypes (or generalization
    relationship)
  • IS-A ( )
  • e.g.
  • existence dependency

STUDENT
UNDER
GRADUATES
110
Semantics of the Relationships (contd)
  • Convert MN Relationships
  • Problems
  • Not specific enough for the detailed modeling
    entities
  • e.g.
  • does not provide a way of telling which of the
    many possible sections a particular student is
    actually enrolled in.
  • does not provide a way of telling which of the
    many actual students are enrolled in a particular
    section.

ENROLL_IN
STUDENTS
SECTIONS
111
Semantics of the Relationships (contd)
  • Solution
  • convert MN relationship into an intersection
    entity (or association entity).
  • an MN relationship usually represents a
    transaction that links the related entities.
  • can be identified by asking what event or
    transaction cause the MN relationship to occur.
  • Intersection entity (association entity)
  • To represent a relationship about which we wish
    to maintain some information.

112
Semantics of the Relationships (contd)
STUDENTS
ENROLLMENT
SECTIONS
John Mary Tania
ACC-1 STA-1 FIN-1 FIN-2
John ACC-1 John FIN-1 John STA-1 Mary ACC-1 Tania
FIN-2
STUDENTS
SECTIONS
ENROLLMENT
113
EER Model of The Student Subsystem
ENROLLMENTS
EERM
STUDENTS
association entities
REGISTRATIONS
PROGRAMS
OFFERINGS
COURSES
characteristic entities
SECTIONS
MEETINGS
FACULTY
114
To Sharpen Your EERM Skill
Job_Description
Tasks
Position
Management
Staff
Skills
Benefits
Stock_Options
Pensions
Employees
115
To Sharpen Your EERM Skill (contd)
  • Answer the following questions based on the EERM
    on the previous slide
  • (1) Does every job description have a related
    position?
  • (2) Can a task exist without a related job
    description?
  • (3) Can a task be part of more than one job
    description?
  • (4) Can a skill exist without a related task?
  • (5) Can an employee be both staff and management
    at the same time?

116
To Sharpen Your EERM Skill (contd)
  • (6) How many staff can a manager supervise?
  • (7) Which employees get both a pension and stock
    options?
  • (8) Can a manager get both pensions and stock
    options?
  • (9) Do all managers get both pensions and stock
    options?
  • (10) Does every recorded position gave an
    employee in it?

117
To Sharpen Your EERM Skill (contd)
  • Draw EERM based on the statements below
  • (1) A country has a capital city.
  • (2) A dining philosopher is using a fork.
  • (3) A file is an ordinary file or a directory
    file.
  • (4) Files contain records.
  • (5) A polygon is composed of an ordered set of
    points.
  • (6) A drawing object is text, a geometrical
    object, or a group.

118
To Sharpen Your EERM Skill (contd)
  • (7) A person uses a computer language on a
    project.
  • (8) Modems and keyboards are input/output
    devises.
  • (9) Object classes may have several attributes.
  • (10) A person plays for a team in a certain year.
  • (11) A route connects two cities.
  • (12) A student takes a course from a professor.

119
To Sharpen Your EERM Skill (contd)
  • Apply ERD and EERM to model the text description
    below.
  • (a) A person has a name, address, and social
    security number. A person may charge time to
    projects and earn a salary. A company has a name,
    address, phone number, and primary product. A
    company hires and fires persons. Person and
    Company have a many-to-many relationship.

120
To Sharpen Your EERM Skill (contd)
  • (b) There are two types of persons workers and
    managers. Each worker works on many projects
    each manager is responsible for many projects. A
    project is staffed by many workers and exactly
    one manager. Each project has a name, budget, and
    internal priority for securing resources.

121
To Sharpen Your EERM Skill (contd)
  • (c) A company is composed of multiple
    departments each department within a company is
    uniquely identified by its name. A department
    usually, but not always, has a manager. Most
    managers manage a department a few managers are
    not assigned to any department. Each department
    manufactures many products while each product is
    made by exactly one department. A product has a
    name, cost, and weight.

122
Components of Structured Analysis
process PSPEC processing narrative
data external entity
PDL process data item
E-R diagram(data modeling) DFD
data store Data Dictionary
(content)
quasicontinuous data flow
control process SA
control item
control store
multiple instances of the same process
control item CFD
(CSPEC bar) a reference to
CSPEC control CSPEC
STD
PAT
123
Structured Analysis Modeling Technique
  • model describe information(data control),
    flow, content.
  • control-oriented applications
    deficiency
  • data-intensive applications

124
Basic Notation
  • DFD
  • process (transformer of information) (I
    data/control?)

  • (Odata/control?)
  • external entity (procedure/consumer of
    information)
  • data item
  • data store (repository of data observed
    by processes)
  • Control flow is not explicit.
  • The truth is that control is excluded in DFD
    intentionally.

125
Basic Notation (contd)
  • DFD can be used to represent a system at any
    level of abstraction. (refine)
  • level 0 context model (a single bubble)
  • information flow continuity I/O to each
    refinement must remain the same. (balancing)
  • No explicit indication of the sequence of
    processing is supplied by the DFD.
  • Explicit procedural representation delayed until
    design.

126
Basic Notation (contd)
  • Content of data (implied by the arrow or
    described by the store)
  • a collection of items using data dictionary.
    (DD) (only content)
  • a need to represent the relationship between
    complex collections of data. (E-R diagram for
    data modeling)

127
Basic Notation (contd)
  • processing narrative describe (usually natural
    language) a process bubble.
  • To specify the processing details in the bubble.
  • inputs to the bubble
  • algorithm applied to the input
  • Output
  • Restrictions limitations imposed on the
    process.
  • Performance characteristics related to the
    process.
  • Design constraints

128
Extensions
  • Data-intensive application
  • Data modeling to describe the relationship
    between complex collections of data. (E-R
    diagram)
  • Control-oriented application
  • To describe/represent control flow and control
    processing as well as data flow and processing.

129
Extensions (contd)
  • (1)Ward Mellor extensions extend SA notation.
  • quasicontinuous data flow (Icontrol /

  • Ocontrol)
  • control process
  • control item
  • control store
  • process (multiple instances of the
  • same process)

130
Extensions (contd)
  • (2)Hatley and Pirbhai Extensions extend on
    representation of the control-oriented aspects.
    (control/event)
  • Notation
  • control flow (separate control flow
    diagram CFD from DFD)
  • reference to a control specification
    (CSPEC)
  • a window into an executive (CSPEC) that controls
    the processes in DFD based on the event that is
    passed through the window.
  • CSPEC (Control Specification)
  • - How the software behaves when a control
    signal is sensed.
  • - Which processes are invoked as a
    consequence of the occurrence of the
    control/event.
  • PSPEC (Process Specification)
  • - To describe the inner workings of a process
    representation.

131
Extensions (contd)
  • Relation between data and control models

Process model
Data input
Data output
DFDs
PSPECs
data conditions occurs when data input a
process results in a control output
Process activators
Control model
data conditions above pressure
refer to CSPEC invoke reduce tank
pressure
CFDs
CSPEC
Control output
Control input
s
132
Extensions (contd)
  • CSPEC if a data conditions occur which refers
    to a CSPEC bar, we must check CSPEC to determine
    what happens when this event occurs.
  • Process activation table (PAT) To indicate which
    processes are activated by a given event that
    flows through the vertical bar.
  • State transition diagram (STD) To indicate how
    the system moves from state to state (behavior
    model)
  • state, any observable mode of behavior
  • events, cause the system to change state

133
Data Dictionary
  • precise, rigorous definitions of all data
    elements pertinent to the system.
  • usually contain the following information
  • Name, Alias, Where used/How used, Content
    description, supplementary information.
  • Content description notation
  • / / /
    n / ( ) / composed of and
    selection repetition option comments

recorded automatically from the flow models
134
Fundamental Issue
Conventional I data/control O data/control
in DFD
Ward-Mellor I/O data control I/O control in DFD
Hatley-Pirbhai I/O data in DFD I/O control in DFD
135
SA and its Extension
  • Summary
  • (1)Conventional
  • Ward-Mellor
  • Hatley-Pirbhai

136
SA and its Extension (contd)
  • (2)Modeling
  • (1) information (control data)
  • flow and content --- DFD / CFD
  • (2) functionality --- data process (DFD)
  • (3) behavior --- CSPEC (STD)

137
Balancing EERD against DFD
  • Every data store on the DFD must correspond to an
    entity type, or a relationship, or a combination
    of an entity type and relationship.
  • If there is a store on the DFD that does not
    appear on the EERD, something is wrong and if
    there is an entity or relationship on the ERD
    that does not appear on the DFD, something is
    wrong.

138
The Analysis Process
build a prototype
requirements elicitation
develop Specification
the problem
Review
create analysis models
139
3.3 Object-oriented (OO) Software Engineering
140
Object-Oriented Software Engineering
Software Systems
Object
Behavior
Function
Data Flow Diagram
Class Diagram
State Chart
141
Steps of Analysis An Example Using OO Approach
  • Define use cases
  • Extract candidate classes
  • Establish basic class relationships
  • Define a class hierarchy
  • Identify attributes for each class
  • Specify methods that service the attributes
  • Indicate how classes/objects are related
  • Build a behavioral model

142
Application and Solution Domain
Application Domain
Solution Domain
Application Domain Model
System Model
UML Package
MapDisplay
TrafficControl
SummaryDisplay
FlightPlanDatabase
TrafficController
Aircraft
Airport
TrafficControl
FlightPlan
143
Concepts and Phenomena
  • Phenomenon (object) An object instance in the
    world of a domain,
  • E.g. My black watch
  • Concept (object class) Describes the properties
    of phenomena that are common,
  • E.g. Black watches
  • A concept is a 3-tuple
  • Its Name distinguishes it from other concepts.
  • Its Purpose are the properties that determine if
    a phenomenon is a member of a concept.
  • Its Members are the phenomena which are part of
    the concept.

144
Concepts and Phenomena (contd)
Members
Purpose
Name
Clock
  • Modeling Development of abstractions to answer
    specific questions about a set of phenomena while
    ignoring irrelevant details.

145
Class
  • Class
  • An 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
  • Retained information
  • Needed services
  • Multiple
Write a Comment
User Comments (0)
About PowerShow.com