Introduction to Software Engineering

1
Introduction to Software Engineering

• Fall 2008
• Csci501
• H. Reza
• reza_at_aero.und.edu

2
Software?

• A textbook description of software may take the
  following form
• Instructions (or computer program) when executed
  provide the desired function and perfromance
• data structures that enables the program to
  adequately manipulate information
• documents that describe the operations and use of
  the program

3
Software charactersitics

• developed or engineered, it is not manufactured
• does not wear out
• are custom built

4
Software applications

• System software
• a collection of program written to service other
  programs (e.g., compilers)
• Real-time sofware
• systems that monitiors/analyzes /controls
  rea-world events
• Embedded software
• a program that resides in ROM and is used to
  control products and systems for the consumer
• AI softwrae
• make use of nonnumerical algorithms to solve
  complex problems

5
Software Engineering 1

• Engineer?
• Not a job description
• A title descrbing the holderss qualifications
• One that successfully complete an education,
  obtain requierd expereicnes, demonstrate
  competency, and agree to obey a code of conduct
  and ethics
• David Parnas
• Software Engineering?
• use of sound engieering principles in order to
  obtain economically software that is reliable and
  works efficiently on real machines
• The title of software engineer should be
  reserved for the graduates of future acccredited
  software engineering programmes

6
Software Engineering

• What is Software Engineering?
• A modeling activity
• Used to manage complexity
• E.g., system models in OO, or Data flow models
• Problem-solving activity
• Used models for possible solution
• Knowledge acquisition activity
• Used to collect, and organize data into info
• Rational-driven activity
• Needed to capture the context in which certain
  decisions were made

7
Software design

• There are two ways of constructing a software
  Tony Hoare
• One way is to make it so simple there are
  obviously no deficiencies and the other way is to
  make it so complicated that there are no obvious
  deficiencies
• Software is built on abstraction
• abstraction
• Matters to all kind of users
• Constitutes the essences of software development

8
What is modeling?

• Modeling?
• One of the basic methods of science
• Refers to an abstract representation of a system
• enable modeler to investigate certain properties
  of a system (e.g., safety property)
• Developed incrementally
• Driven by the modelers perception of which
  aspects of the software matter most
  (abstraction), where the risks are, and possible
  tool support
• Confused by specification model is not
  specification because model does not distinguish
  required behaviors from incidental properties of
  description provided

9
Engineering a problem solving activities?

• Engineering is a problem-solving activity
• the engineering methods consists of
• Formulate the problem
• Analyze the problem
• Search for solutions
• Decide on the appropriate solution
• Specify the solution
• Software engineering is an engineering activity

10
Software Engineering Concepts

• The common terms and concepts used in
  construction and development of a system
• System?
• A collection of interconnected parts
• System requirements (concrete user requirements)
• Product?
• Any artifact that is produced during the
  development (e.g., document or piece of software)
• Deliverable products
• Any product that must be delivered to a client
  (e.g., SPEC)

11
More on engineering terms

• Task
• Any atomic unit of work that can be managed
• Resources
• Assets that are used to achieve work (e.g.,
  labor, equipment)

12
Some examples
13
Functional and Non-functional requirements (NFR),
Domain Requiremnts

• Functional requirements
• Statements of services the system should (or
  should not) provide
• Nonfunctional requirements (NFR)
• Constraints on the services or functions offered
  by the system
• E.g.,
• Timing constraints
• Constraints on the development process and
  standards
• Applies to the system as a whole
• Domain requirements
• Requirements coming from application domain of
  the system
• Reflects the main features of that domain
• Could be functional or non-functional

14
Notations?

• Notations (languages)
• Graphical/textual set of rules for representing a
  model
• C.A.R. Hoare remark on notation
• Our ability to solve a problem often hinges on
  the notations we choose. The classic example is
  arithmetic using roman numerals. Try multiplying
  LIV by VIII! With Arabic numerals, however,
  multiplication can be taught to school children.
  Although inappropriate for doing arithmetic,
  roman numerals are appropriate elsewhere. They
  are excellent for carving into stone
• Textual, graphical, mathematical notations
• E.g., UMLOMG 2001, ZSpivey92, DFD De Marco,
  1978

15
Method

• Method?
• A repeatable technique that specifies the steps
  involved in solving a specific problem
• Examples
• A recipe for cooking a specific dish
• A sorting algorithm for ordering elements
• Configuration mgt for tracking change

16
Methodology

• Methodologies?
• A collection of methods for solving a class of
  problems
• Specifies how and when each method should be used
• Examples
• A seafood cookbook, which contains a collection
  of recipes
• OMT Rumbaugh et al., 1991
• Booch methodology Booch, 1994

17
More on Methodology

• Software lifecycle is a methodology
• Decomposes the process into activities
• OMT provides methods for three activities
• Analysis, system design, object design
• Unified Software Development Process includes
• Analysis, Design, and Requirement capturing

18
The Waterfall model

• The Waterfall model activities include
• Requirement Analysis and definition
• System and Software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance

19
Requirement analysis and Specification (what)

• Requirement analysis and specification
• Undertaken after a feasibility study
• To identify and document the exact requirements
  for the systems
• Performed by the customer, the developer, and a
  marking organization
• May produce user manuals and plans for the system
  test

20
System design and specification (how)

• Design a software to meet the requirements
• Split into
• Architectural design (high level design)
• Detailed design (low level design)

21
Implementation (coding and testing)

• The actual code that will meet the design
  specification is produced
• Other products may include
• Prototypes
• Tests
• Test derivers

22
Implementation (integration and system testing)

• All the tested components are integrated
• Testing
• element of a broader topic referred to
  verification and validation
• Verification Are we building the product right?
• Validation Are we building the right product?
• The whole system is tested (system test)
• Integration Test documentation

23
Software Requirements Specification (SRS)

• Specification?
• An official document of what the system
  developers should produced
• Characterizes a system,.. object,.. process, ..
• Abstract (from any realization)
• Informal but rigorous, flexible
• Formal mathematical (safety critical system)
• Standard ( e.g., DOD, IEEE/ANSI 830-1998

24
More on Specification

• A single term
• means different things in the software lifecycle
• uses for a product and the corresponding process
• a statement of agreement (contract) between
• producer and consumer of a service
• implementer and user
• Describes ALL desirable properties
• Requires some kind of structuring

25
Software Specification and level of abstractions

• Level of abstractions
• Requirements (System) Specification
• Design (Architecture) Specification
• Module/Object Specification

26
What do we mean by GOOD specifications?

• Writing a correct specification can be as
  difficult as writing a correct program
• A specification must be
• Adequate
• Consistent
• Unambiguous
• Complete w.r.t higher level of abstractions
• Must be satisfied by lower level
• Must satisfy the higher level
• Minimal

27
SPECIFICATION Used by whom?

• specification can be used by different
  stakeholders
• Clients
• Domain experts
• Users
• Architects
• Programmers
• tools

28
Specify when?

• There are multiple stages in the software
  lifecycle at which specifications may be used
• When modeling the domain
• When elaborating the goals/properties/constraints
• When designing a functional model
• When designing architecture
• When modifying or reengineering the software

29
Uses of specification 1

• Statement of user requirements
• major failures occur because of misunderstandings
  between the producer and the user
• "The hardest single part of building a software
  system is deciding precisely what to build"
• F. Brooks

30
Uses of specification 2

• Statement of the interface between the machine
  and the controlled environment
• serious undesirable effects can result due to
  misunderstandings between software engineers and
  domain experts about the phenomena affecting the
  control function to be implemented by software

31
Uses of specification 3

• Statement of requirements for implementation
• design process is a chain of specification (i.e.,
  definition)implementationverification steps
• requirements specification refers to definition
  of external behavior
• design specification must be verified against it
• design specification refers to definition of the
  software architecture
• code must be verified against it

32
Uses of specification 4

• A reference point during maintenance
• corrective maintenance only changes
  implementation
• adaptive and perfective maintenance occur because
  of requirements changes
• requirements specification must change accordingly

33
Complete

• Internal completeness
• the specification must define any new concept or
  terminology that it uses
• glossary helpful for this purpose
• the specification must document all the needed
  requirements (or user needs)
• Difficulty?
• when should one stop?

34
Incremental

• Referring to the specification process
• start from a sketchy document and progressively
  add details
• Referring to the specification document
• document is structured and can be understood in
  increments

35
Classification of specification styles

• Informal
• Natural languages (user requirements)
• Structured language specifications (system
  requirements)
• Enforces special format (e.g. forms for
  describing I/O)
• Semi formal
• UML, DFD, ERD
• Formal

36
Formal Specification Paradigms

• Formal specification techniques differ by the
  particular specification paradigm they rely on
• History-based specification (temporal logics)
• State-based specification (e.g., Z)
• Transition-based specification (Statecharts)
• Functional specifications
• Algebraic specifications (LARCH)
• Operational (or executable) specifications (Petri
  nets)

37
Example 1

• Specification of a geometric figure E

E can be drawn as follows 1. Select two points
P1 and P2 on a plane 2. Get a string of a certain
length and fix its ends to P1 and P2 3. Position
a pencil as shown in next figure 4. Move the pen
clockwise, keeping the string tightly stretched,
until you reach the point where you started
drawing
this is an operational specification
38
A descriptive specification

• Geometric figure E is describe by the following
  equation
• ax2 by2 c 0
• where a, b, and c are suitable constants

39
Another example

• Let a be an array of n elements. The result of
  its sorting is an array b of n elements such that
  the first element of b is the minimum of a (if
  several elements of a have the same value, any
  one of them is acceptable) the second element of
  b is the minimum of the array of n-1 elements
  obtained from a by removing its minimum element
  and so on until all n elements of a have been
  removed.

OP
The result of sorting array a is an array b
which is a permutation of a and is sorted.
DES
40
How to verify a specification?

• Observe dynamic behavior of specified system
• simulation,
• prototyping,
• testing specs
• Analyze properties of the specified system
• Proof
• reasoning

41
References and acknowledgments

• 1. Axel Van Lamsweede. Formal Specification a
  Roadmap, the future of software engineering, ACM
  Press 2000
• 2. A Fundamental of Software Engineering, 2nd
  edition, by Carlo Ghezzi et al, Prentice hall,
  2003
• 3 Sommerville. Software Engineering, 8th
  edition, Addison Wesley