Unit 1 Introduction to Software Engineering - · PDF fileIntroduction to Software Engineering...

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


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)



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)



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



6/50


7/50


8/50


Contents


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


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



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



12/50



13/50

RE is a critical step real-world goals functions constraints

End result is a precise specification ofsoftware behaviour


Develop the right systemvs.

Develop the system right


14/50



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)



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



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



18/50



19/50

A system includesSoftware Requirements

In a system with software, softwarerequirements are derived from systemrequirements

hardware software firmware people

information techniques facilities services


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


21/50


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


22/50


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


23/50


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


24/50


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


25/50



26/50



27/50


Software requirements should be clear unambiguous quantifiable

Precise requirements enable their validation their implementation to be verified their costs to be estimated


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


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



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



31/50

Requirements management include Requirements Elicitation, Specification and

Modelling Prioritization Requirements Dependencies and Impact

Analysis Requirements Negotiation Quality Assurance



32/50


Contents


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


34/50

Software Design


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Unit 1 Introduction to Software Engineering - · PDF fileIntroduction to Software Engineering...

Documents

Transcript of Unit 1 Introduction to Software Engineering - · PDF fileIntroduction to Software Engineering...