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