unit 1 introduction to software engineering - · pdf fileintroduction to software engineering...
TRANSCRIPT
Unit 1Introduction to
Software Engineering
João M. Fernandes
Universidade do Minho – Portugal
Introduction to Software Engineering
2/50
1. Software Engineering2. Software Requirements3. Software Design
Contents
Introduction to Software Engineering
3/50
Engineering building useful things using science application of science to the needs of
humanity application of knowledge, mathematics, and
practical experience to design usefulobjects/processes.
1967: Software Engineering (SE)
Software Engineering
Introduction to Software Engineering
4/50
Term software eng. was provocative Software must be built as other
engineering artefacts (bridge, car, TV set) IEEE CS defines SE as
1. The application of a systematic, disciplined,quantifiable approach to the development,operation, and maintenance of software; thatis, the application of engineering to software
2. The study of approaches as in (1)
Software Engineering
Introduction to Software Engineering
5/50
The SWEBOK Knowledge Areas (KAs)1. Software requirements2. Software design3. Software construction4. Software testing5. Software maintenance6. Software configuration management7. Software engineering management8. Software engineering process9. Software engineering tools and methods10. Software quality
Software Engineering
Introduction to Software Engineering
6/50
Introduction to Software Engineering
7/50
Introduction to Software Engineering
8/50
1. Software Engineering2. Software Requirements3. Software Design
Contents
Introduction to Software Engineering
9/50
“The hardest single part of building asoftware system is deciding preciselywhat to build. (...) No other part ofthe work so cripples the resultingsystem if done wrong. No other partis more difficult to rectify later.”
Frederick P. Brooks
Software Requirements
Introduction to Software Engineering
10/50
Software Requirements KA: elicitation,analysis, specification, and validation ofsoftware requirements
SE projects are vulnerable when theseactivities are performed poorly
Software requirements are the needs andrestrictions of a software product
Requirements engineering (RE) is thesystematic handling of requirements
Software Requirements
Introduction to Software Engineering
11/50
RE is concerned with establishing what the system should do the system’s desired properties the constraints on system operation the constraints on the software process
RE is not simply a technical process RE is about the communication between
the customers/users and the developers
Software Requirements
Introduction to Software Engineering
12/50
Software Requirements
Introduction to Software Engineering
13/50
RE is a critical step real-world goals functions constraints
End result is a precise specification ofsoftware behaviour
Software Requirements
Develop the right systemvs.
Develop the system right
Introduction to Software Engineering
14/50
Software Requirements
Introduction to Software Engineering
15/50
Requirements describe how a softwareproduct should perform
A requirement is (IEEE 610.12-1990)1. a condition or capability needed by a user to
solve a problem or achieve an objective2. a condition or capability that must be met or
possessed by a system or system componentto satisfy a contract, standard, specification,or other formally imposed documents
3. a documented representation of a conditionor capability as in (1) or (2)
Software Requirements
Introduction to Software Engineering
16/50
Software requirements are properties exhibited by software are the combined result of requirements from
different people and from the environment include user and organizational needs are the critical determinants of software
quality should be independent of design: “what”
rather than “how” should be verifiable
Software Requirements
Introduction to Software Engineering
17/50
User requirements Natural language + informal diagrams describe software functions + constraints are influenced by users’ likes and dislikes, and
by political and organisational issues
System requirements must be precise define exactly what to implement set out the system’s functions, services and
operational constraints in detail may be part of the contract
Software Requirements
Introduction to Software Engineering
18/50
Software Requirements
Introduction to Software Engineering
19/50
A system includesSoftware Requirements
In a system with software, softwarerequirements are derived from systemrequirements
hardware software firmware people
information techniques facilities services
Introduction to Software Engineering
20/50
Software Requirements Requirements are written at different
levels of detail for different readers User requirements do NOT indicate how
the system will be implemented System requirements specify precisely
what the system will do
Introduction to Software Engineering
21/50
Software Requirements
Functional requirements (capabilities) are statements of services the system
provides specify how the system should behave describe the functions that the software is
to execute may state what the system should not do should be independent of any technology
Introduction to Software Engineering
22/50
Software Requirements
Non-functional requirements (NFRs) are constraints on the services of the system restrict the solution include timing constraints, constraints on the
development process and standards often apply to the system, rather to individual
features are known as quality requirements or
constraints do not alter the product’s essential
functionality
Introduction to Software Engineering
23/50
Software Requirements
Types of NFRs Look & Feel
The product shall comply with corporatebranding standards
Usability and HumanityThe product shall be easy to use
PerformanceThe product shall identify the person in 0.25s
OperationalThe product shall interface with the mapsdatabase
Introduction to Software Engineering
24/50
Software Requirements
Types of NFRs Maintainability and Support
The product shall be readily portable to Linux Security
The product shall ensure that only authorizedusers have access to the data
Cultural and PoliticalThe product shall use Brazilian spelling
LegalThe product shall comply with the ISO 9001certification
Introduction to Software Engineering
25/50
Software Requirements
Introduction to Software Engineering
26/50
Software Requirements
Introduction to Software Engineering
27/50
Software Requirements
Software requirements should be clear unambiguous quantifiable
Precise requirements enable their validation their implementation to be verified their costs to be estimated
Introduction to Software Engineering
28/50
Requirements Analysis detects and resolves conflicts between
requirements discovers the bounds of the software specifies how the software must interact
with its environment elaborates system requirements to derive
software requirements
Requirements Engineering Process
Introduction to Software Engineering
29/50
Use of models aid in understanding theproblem
Conceptual models comprise models ofentities from the problem domain and howthey are related
Several kinds of models can be used context diagrams, data/control flows, use cases,
user interactions, state models, event traces,class models, data models, feature models
Requirements Engineering Process
Introduction to Software Engineering
30/50
Factors that affect the choice of model The nature of the problem The expertise of the software engineer The process requirements of the customer The availability of methods and tools
Start by building a model of the softwarecontext
UML is the current de-facto standard formodelling software
Requirements Engineering Process
Introduction to Software Engineering
31/50
Requirements management include Requirements Elicitation, Specification and
Modelling Prioritization Requirements Dependencies and Impact
Analysis Requirements Negotiation Quality Assurance
Requirements Engineering Process
Introduction to Software Engineering
32/50
1. Software Engineering2. Software Requirements3. Software Design
Contents
Introduction to Software Engineering
33/50
Design is defined as both: the process of defining the architecture,
components, interfaces of a system; and The result of that process
In design software requirements areanalyzed to produce a description of thesoftware’s internal structure
A software design describes the softwareand the interfaces between its components
It also describe the components at a levelof detail that enable their construction
Software Design
Introduction to Software Engineering
34/50
Software Design
Introduction to Software Engineering
35/50
Software design plays an important rolein developing software
The design models form a blueprint of thesolution to be implemented
We can evaluate these models to decideif they will allow us to fulfil the variousrequirements
We can examine and evaluate variousalternative solutions and trade-offs
We can use the resulting models to planthe subsequent development activities
Software Design
Introduction to Software Engineering
36/50
Software design fits betweenrequirements analysis and construction: Software architectural design: describing
software’s top-level structure and organizationand identifying the various components
Software detailed design: describing eachcomponent to allow for its construction
The output of this process is a set ofmodels and artefacts that record themajor decisions that have been taken
Software Design
Introduction to Software Engineering
37/50
The enabling techniques are key notionsfundamental to design: Abstraction Coupling and cohesion Decomposition and modularization Encapsulation/information hiding Separation of interface and implementation Sufficiency, completeness and primitiveness
Abstraction is a process that selectivelyremoves information from a descriptionto focus on the information that remains
Software Design
Introduction to Software Engineering
38/50
For design, two key abstractions areparameterization and specification
Abstraction by specification leads to threemajor kinds of abstraction: procedural,data abstraction, and control abstraction
Coupling is the strength of the relationsbetween modules
Cohesion is how the elements making upa module are related
Decomposing a system means dividing itinto a number of smaller ones
Software Design
Introduction to Software Engineering
39/50
Encapsulation/information hiding:grouping the elements of an abstractionand making them inaccessible
Separating interface and implementation:defining a component by a publicinterface separate from the details of howthe component is realized
Achieving sufficiency, completeness, andprimitiveness means that a componentcaptures all the important characteristicsof an abstraction, and nothing more
Software Design
Introduction to Software Engineering
40/50
A number of key issues must be dealt withwhen designing software
Some are quality concerns that allsoftware must address (performance)
Another is how to decompose, organize,and package software components
Other issues deal with aspects thataddress some of the supporting domains
Such issues cross-cut the system’sfunctionality and are designated aspects
Software Design
Introduction to Software Engineering
41/50
Aspects tend not to be units of functionaldecomposition, but rather properties thataffect the performance or semantics ofthe components Concurrency Control and Handling of Events Distribution of Components Exception Handling and Fault Tolerance Interaction and Presentation Data Persistence
Software Design
Introduction to Software Engineering
42/50
A view represents a partial aspect of asoftware architecture that shows specificproperties of a software system
Distinct views pertain to distinct issuesassociated with software design: the logical view (functional requirements) the process view (concurrency issues) the physical view (distribution issues) the development view (how the design is
broken down into implementation units)
Software Design
Introduction to Software Engineering
43/50
Different terms, like behavioural vs.functional vs. structural vs. data modellingviews are also used
A software design is a multi-facetedartefact, composed of relativelyindependent and orthogonal views
A design pattern is a common solution to acommon problem in a given context: Creational patterns (e.g., factory, prototype) Structural patterns (e.g., adapter, proxy) Behavioural patterns (e.g., state, iterator)
Software Design
Introduction to Software Engineering
44/50
Reuse can be achieved by designingfamilies of software, also known assoftware product lines
This can be done by: identifying the commonalities among
members of such families. using reusable components to account
for the variability among family members
A framework can be extended byappropriately instantiating plug-ins
Software Design
Introduction to Software Engineering
45/50
Many notations and languages exist torepresent software design artefacts
They describe the structural vs. thebehavioural views
The following notations describe andrepresent the structural aspects of asoftware design.
Architecture description languages (ADLs)are textual, often formal, languages usedto describe a software architecture interms of components and connectors
Software Design
Introduction to Software Engineering
46/50
Class and object diagrams represent a setof classes/objects and their relations
Component diagrams represent a set ofcomponents and their interrelationships
Class responsibility collaborator cards(CRCs) denote the names of components,their responsibilities, and theircollaborating components’ names
Deployment diagrams represent a set ofnodes and their interrelationships, tomodel the physical aspects of a system
Software Design
Introduction to Software Engineering
47/50
Entity-relationship diagrams (ERDs)represent conceptual models of dataInterface description languages (IDLs)are languages used to define theinterfaces of software components
Jackson structure diagrams describe thedata structures in terms of sequence,selection, and iteration
Structure charts describe the callingstructure of programs
Software Design
Introduction to Software Engineering
48/50
Notations to describe behaviour Activity diagrams show the control flow
from activity to activity Collaboration diagrams show the
interactions among objects, where theemphasis is on the messages exchanged
Data flow diagrams (DFDs) show dataflow among a set of processes
Flowcharts represent the flow of controland the actions to be performed
Software Design
Introduction to Software Engineering
49/50
Sequence diagrams show the interactionsamong objects, emphasising the time-ordering of messages
State transition diagrams show the controlflow in a state machine
Pseudo-code and program designlanguages are structured-programming-like languages used to describe thebehaviour of a procedure or method
Software Design
Introduction to Software Engineering
50/50
Abran A, Moore JW, Bourque P, Dupuis R (eds.); “Guideto the Software Engineering Body of Knowledge: 2004Edition – SWEBOK”, IEEE CS Press, 2004
Robertson S, Robertson J; “Mastering the RequirementsProcess”, 2nd edition, Addison-Wesley, 2006, ISBN 0-321-41949-9
Further Reading