Unit 1 Introduction to Software Engineering

Transcription

1 Unit 1 Introduction to Software Engineering João M. Fernandes Universidade do Minho Portugal

2 Contents 1. Software Engineering 2. Software Requirements 3. Software Design 2/50

3 Software Engineering Engineering building useful things using science application of science to the needs of humanity application of knowledge, mathematics, and practical experience to design useful objects/processes. 1967: Software Engineering (SE) 3/50

4 Software Engineering 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; that is, the application of engineering to software 2. The study of approaches as in (1) 4/50

5 Software Engineering The SWEBOK Knowledge Areas (KAs) 1. Software requirements 2. Software design 3. Software construction 4. Software testing 5. Software maintenance 6. Software configuration management 7. Software engineering management 8. Software engineering process 9. Software engineering tools and methods 10. Software quality 5/50

6 6/50

7 7/50

8 Contents 1. Software Engineering 2. Software Requirements 3. Software Design 8/50

9 Software Requirements The hardest single part of building a software system is deciding precisely what to build. (...) No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Frederick P. Brooks 9/50

10 Software Requirements Software Requirements KA: elicitation, analysis, specification, and validation of software requirements SE projects are vulnerable when these activities are performed poorly Software requirements are the needs and restrictions of a software product Requirements engineering (RE) is the systematic handling of requirements 10/50

11 Software Requirements 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 11/50

12 Software Requirements 12/50

13 Software Requirements RE is a critical step real-world goals functions constraints End result is a precise specification of software behaviour Develop the right system vs. Develop the system right 13/50

14 Software Requirements 14/50

15 Introduction to Software Engineering Software Requirements Requirements describe how a software product should perform A requirement is (IEEE ) 1. a condition or capability needed by a user to solve a problem or achieve an objective 2. a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents 3. a documented representation of a condition or capability as in (1) or (2) 15/50

16 Software Requirements 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 16/50

17 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 Software 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 17/50

18 Software Requirements 18/50

19 Software Requirements A system includes hardware information software techniques firmware facilities people services In a system with software, software requirements are derived from system requirements 19/50

20 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 20/50

21 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 21/50

22 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 22/50

23 Software Requirements Types of NFRs Look & Feel The product shall comply with corporate branding standards Usability and Humanity The product shall be easy to use Performance The product shall identify the person in 0.25s Operational The product shall interface with the maps database 23/50

24 Software Requirements Types of NFRs Maintainability and Support The product shall be readily portable to Linux Security The product shall ensure that only authorized users have access to the data Cultural and Political The product shall use Brazilian spelling Legal The product shall comply with the ISO 9001 certification 24/50

25 Software Requirements 25/50

26 Software Requirements 26/50

27 Software Requirements Software requirements should be clear unambiguous quantifiable Precise requirements enable their validation their implementation to be verified their costs to be estimated 27/50

28 Requirements Engineering Process 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 28/50

29 Requirements Engineering Process Use of models aid in understanding the problem Conceptual models comprise models of entities from the problem domain and how they 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 29/50

30 Requirements Engineering Process 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 software context UML is the current de-facto standard for modelling software 30/50

31 Requirements Engineering Process Requirements management include Requirements Elicitation, Specification and Modelling Prioritization Requirements Dependencies and Impact Analysis Requirements Negotiation Quality Assurance 31/50

32 Contents 1. Software Engineering 2. Software Requirements 3. Software Design 32/50

33 Design is defined as both: Software Design the process of defining the architecture, components, interfaces of a system; and The result of that process In design software requirements are analyzed to produce a description of the software s internal structure A software design describes the software and the interfaces between its components It also describe the components at a level of detail that enable their construction 33/50

34 Software Design 34/50

35 Introduction to Software Engineering Software Design Software design plays an important role in developing software The design models form a blueprint of the solution to be implemented We can evaluate these models to decide if they will allow us to fulfil the various requirements We can examine and evaluate various alternative solutions and trade-offs We can use the resulting models to plan the subsequent development activities 35/50

36 Software Design Software design fits between requirements analysis and construction: Software architectural design: describing software s top-level structure and organization and identifying the various components Software detailed design: describing each component to allow for its construction The output of this process is a set of models and artefacts that record the major decisions that have been taken 36/50

37 Introduction to Software Engineering The enabling techniques are key notions fundamental to design: Abstraction Software Design Coupling and cohesion Decomposition and modularization Encapsulation/information hiding Separation of interface and implementation Sufficiency, completeness and primitiveness Abstraction is a process that selectively removes information from a description to focus on the information that remains 37/50

38 Introduction to Software Engineering Software Design For design, two key abstractions are parameterization and specification Abstraction by specification leads to three major kinds of abstraction: procedural, data abstraction, and control abstraction Coupling is the strength of the relations between modules Cohesion is how the elements making up a module are related Decomposing a system means dividing it into a number of smaller ones 38/50

39 Software Design Encapsulation/information hiding: grouping the elements of an abstraction and making them inaccessible Separating interface and implementation: defining a component by a public interface separate from the details of how the component is realized Achieving sufficiency, completeness, and primitiveness means that a component captures all the important characteristics of an abstraction, and nothing more 39/50

40 Software Design A number of key issues must be dealt with when designing software Some are quality concerns that all software must address (performance) Another is how to decompose, organize, and package software components Other issues deal with aspects that address some of the supporting domains Such issues cross-cut the system s functionality and are designated aspects 40/50

41 Software Design Aspects tend not to be units of functional decomposition, but rather properties that affect the performance or semantics of the components Concurrency Control and Handling of Events Distribution of Components Exception Handling and Fault Tolerance Interaction and Presentation Data Persistence 41/50

42 Software Design A view represents a partial aspect of a software architecture that shows specific properties of a software system Distinct views pertain to distinct issues associated 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) 42/50

43 Different terms, like behavioural vs. functional vs. structural vs. data modelling views are also used A software design is a multi-faceted artefact, composed of relatively independent and orthogonal views A design pattern is a common solution to a common problem in a given context: Software Design Creational patterns (e.g., factory, prototype) Structural patterns (e.g., adapter, proxy) Behavioural patterns (e.g., state, iterator) 43/50

44 Software Design Reuse can be achieved by designing families of software, also known as software 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 by appropriately instantiating plug-ins 44/50

45 Introduction to Software Engineering Software Design Many notations and languages exist to represent software design artefacts They describe the structural vs. the behavioural views The following notations describe and represent the structural aspects of a software design. Architecture description languages (ADLs) are textual, often formal, languages used to describe a software architecture in terms of components and connectors 45/50

46 Introduction to Software Engineering Software Design Class and object diagrams represent a set of classes/objects and their relations Component diagrams represent a set of components and their interrelationships Class responsibility collaborator cards (CRCs) denote the names of components, their responsibilities, and their collaborating components names Deployment diagrams represent a set of nodes and their interrelationships, to model the physical aspects of a system 46/50

47 Software Design Entity-relationship diagrams (ERDs) represent conceptual models of data Interface description languages (IDLs) are languages used to define the interfaces of software components Jackson structure diagrams describe the data structures in terms of sequence, selection, and iteration Structure charts describe the calling structure of programs 47/50

48 Introduction to Software Engineering Software Design Notations to describe behaviour Activity diagrams show the control flow from activity to activity Collaboration diagrams show the interactions among objects, where the emphasis is on the messages exchanged Data flow diagrams (DFDs) show data flow among a set of processes Flowcharts represent the flow of control and the actions to be performed 48/50

49 Software Design Sequence diagrams show the interactions among objects, emphasising the timeordering of messages State transition diagrams show the control flow in a state machine Pseudo-code and program design languages are structured-programminglike languages used to describe the behaviour of a procedure or method 49/50

50 Further Reading Abran A, Moore JW, Bourque P, Dupuis R (eds.); Guide to the Software Engineering Body of Knowledge: 2004 Edition SWEBOK, IEEE CS Press, 2004 Robertson S, Robertson J; Mastering the Requirements Process, 2nd edition, Addison-Wesley, 2006, ISBN /50