1、UNIT11 Software Engineering 11-1 Technical Part11-2 Reading Material 11-1 Technical Part 11-1-1 DefinitionSoftware engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after
2、it has gone into use.In this definition,there are two key phrases:1.Engineering discipline Engineers make things work.They apply theories,methods,and tools where these are appropriate.However,they use them selectively and always try to discover solutions to problems even when there are no applicable
3、 theories and methods.Engineers also recognize that they must work to organizational and financial constraints so they look for solutions within these constraints.2.All aspects of software production Software engineering is not just concerned with the technical processes of software development.It a
4、lso includes activities such as software project management and the development of tools,methods,and theories to support software production.11-1-2 IntroductionsThe Importance of Software EngineeringSoftware engineers adopt a systematic and organized approach to their work,as this is often the most
5、effective way to produce high-quality software.Software engineering is important for two reasons:1.More and more,individuals and society rely on advanced software systems.We need to be able to produce reliable and trustworthy systems economically and quickly.2.It is usually cheaper,in the long run,t
6、o use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project.For most types of systems,the majority of costs are the costs of changing the software after it has gone into use.Software ProcessesThe systematic ap
7、proach that is used in software engineering is sometimes called a software process.A software process is a sequence of activities that leads to the production of a software product.There are four fundamental activities that are common to all software processes.These activities are:1.Software specifi
8、cation,where customers and engineers define the software that is to be produced and the constraints on its operation.2.Software development,where the software is designed and programmed.3.Software validation,where the software is checked to ensure that it is what the customer requires.4.Software evo
9、lution,where the software is modified to reflect changing customer and market requirements.Different types of systems need different development processes.For example,real-time software in an aircraft has to be completely specified before development begins.In e-commerce systems,the specification an
10、d the program are usually developed together.Consequently,these generic activities may be organized in different ways and described at different levels of detail depending on the type of software being developed.Correlation Theory of Software EngineeringSoftware engineering is related to both comput
11、er science and systems engineering:1.Computer science is concerned with the theories and methods that underlie computers and software systems,whereas software engineering is concerned with the practical problems of producing software.Some knowledge of computer science is essential for software engin
12、eers in the same way that some knowledge of physics is essential for electrical engineers.Computer science theory,however,is often most applicable to relatively small programs.Elegant theories of computer science cannot always be applied to large,complex problems that require a software solution.2.S
13、ystem engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role.System engineering is therefore concerned with hardware development,policy and process design and system deployment,as well as software engineering.System engineers a
14、re involved in specifying the system,defining its overall architecture,and then integrating the different parts to create the finished system.They are less concerned with the engineering of the system components(hardware,software,etc.).Structured Analysis and Design TechniqueStructured Analysis and
15、Design Technique(SADT)is a software engineering methodology for describing systems as a hierarchy of functions.Structured Analysis and Design Technique(SADT)is a diagrammatic notation designed specifically to help people describe and understand systems.It offers building blocks to represent entities
16、 and activities,and a variety of arrows to relate boxes.These boxes and arrows have an associated informal semantics.SADT can be used as a functional analysis tool of a given process,using successive levels of details.The SADT method not only allows one to define user needs for IT developments,which
17、 is often used in the industrial Information Systems,but also to explain and present an activitys manufacturing processes and procedures.The SADT supplies a specific functional view of any enterprise by describing the functions and their relationships in a company.These functions fulfill the objecti
18、ves of a company,such as sales,order planning,product design,part manufacturing,and human resource management.The SADT can depict simple functional relationships here and can reflect data and control flow relationships between different functions.1.Top down approachThe structured analysis and design
19、 technique uses a decomposition with the top-down approach.This decomposition is conducted only in the physical domain from an axiomatic design viewpoint.Because of this nonzigzagging process,there is no guarantee of functionality or productivity.Therefore,those methods faded away as the requirement
20、s for software systems increased and the object-oriented method was introduced.2.DiagramsSADT uses two types of diagrams:activity models and data models.It uses arrows to build these diagrams.The SADTs representation is the following(See Figure 11-1):A main box where the name of the process or the a
21、ction is specified On the left-hand side of this box,incoming arrows:inputs of the action.On the upper part,the incoming arrows:data necessary for the action.On the bottom of the box,incoming arrows:means used for the action.On the right-hand side of the box,outgoing arrows:outputs of the action.Fig
22、ure 11-1 SADT basis elementThe semantics of arrows for activities:Inputs enter from the left and represent data or consumables that are needed by the activity.Outputs exit from the right and represent data or products that are produced by the activity.Controls enter from the top and represent comman
23、ds which influence the execution of an activity but are not consumed.Mechanisms identify the means,components or tools used to accomplish the activity.Represents allocation of activities.The semantics of arrows for data:Inputs are activities that produce the data.Outputs consume the data.Controls in
24、fluence the internal state of the data.Object-Oriented Software EngineeringObject-oriented software engineering(commonly known by acronym OOSE)is an object modeling language and methodology.OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB.It is the first object-oriented design metho
25、dology to employ use cases to drive software design.It also uses other design products similar to those used by Object-modeling technique.The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology.After success in the marketplace,other tool vendors also supported OO
26、SE.After Rational Software bought Objectory AB,the OOSE notation,methodology,and tools became superseded.As one of the primary sources of the Unified Modeling Language(UML),concepts and notation from OOSE have been incorporated into UML.The methodology part of OOSE has since evolved into the Rationa
27、l Unified Process(RUP).The OOSE tools have been replaced by tools supporting UML and RUP.OOSE has been largely replaced by the UML notation and by the RUP methodology.Software CrisisSoftware crisis was a term used in the early days of computing science.The term was used to describe the impact of rap
28、id increases in computer power and the complexity of the problems that could be tackled.In essence,it refers to the difficulty of writing correct,understandable,and verifiable computer programs.The roots of the software crisis are complexity,expectations,and change.The term“software crisis”was coine
29、d by some attendees at the first NATO Software Engineering Conference in 1968 at Garmisch,Germany.An early use of the term is in Edsger Dijkstras 1972 ACM Turing Award Lecture:The major cause of the software crisis is that the machines have become several orders of magnitude more powerful!To put it
30、quite bluntly:as long as there were no machines,programming was no problem at all,when we had a few weak computers,programming became a mild problem,and now we have gigantic computers,programming has become an equally gigantic problem.The causes of the software crisis were linked to the overall comp
31、lexity of hardware and the software development process.The crisis manifested itself in several ways:Projects running over-budget.Projects running over-time.Software was very inefficient.Software was of low quality.Software often did not meet requirements.Projects were unmanageable and code difficul
32、t to maintain.Software was never delivered.Many of the software problems were caused by increasingly complex hardware.In his essay,Dijkstra noted that the newer computers in his day“embodied such serious flaws that he felt that with a single stroke the progress of computing science had been retarded
33、 by at least ten years”.He also believed that the influence of hardware on software was too frequently overlooked.Various processes and methodologies have been developed over the last few decades to improve software quality management,with varying degrees of success.However,it is widely agreed that
34、there is no“silver bullet”that is,no single approach that will prevent project overruns and failures in all cases.In general,software projects that are large,complicated,poorly-specified,and involve unfamiliar aspects,are still particularly vulnerable to large,unanticipated problems.11-1-3 Applicati
35、on Case or Example Software Design And ImplementationSoftware design and implementation is the stage in the software engineering process at which an executable software system is developed.For some simple systems,software design and implementation is software engineering,and all other activities are
36、 merged with this process.However,for large systems,software design and implementation is only one of a set of processes(requirements engineering,verification and validation,etc.)involved in software engineering.Design and implementation are closely linked and you should normally take implementation
37、 issues into account when developing a design.For example,using the UML to document a design may be the right thing to do if you are programming in an object-oriented language such as Java or C#.In the early stages of the design process,I think there are three models that are particularly useful for
38、 adding detail to use case and architectural models:1.Subsystem models,which that show logical groupings of objects into coherent subsystems.These are represented using a form of class diagram with each subsystem shown as a package with enclosed objects.Subsystem models are static(structural)models.
39、2.Sequence models,which show the sequence of object interactions.These are represented using a UML sequence or a collaboration diagram.Sequence models are dynamic models.3.State machine model,which show how individual objects change their state in response to events.These are represented in the UML
40、using state diagrams.State machine models are dynamic models.A wilderness weather stationTo help monitor climate change and to improve the accuracy of weather forecasts in remote areas,the government of a country with large areas of wilderness decides to deploy several hundred weather stations in re
41、mote areas.These weather stations collect data from a set of instruments that measure temperature and pressure,sunshine,rainfall,wind speed,and wind direction.Wilderness weather stations are part of a larger system(See Figure 11-2),which is a weather information system that collects data from weathe
42、r stations and makes it available to other systems for processing.The systems in Figure 11-2 are:Figure 11-2 The weather stations environment1.The weather station system.This is responsible for collecting weather data,carrying out some initial data processing,and transmitting it to the data manageme
43、nt system.2.The data management and archiving system.This system collects the data from all of the wilderness weather stations,carries out data processing and analysis,and archives the data in a form that can be retrieved by other systems,such as weather forecasting systems.3.The station maintenance
44、 system.This system can communicate by satellite with all wilderness weather stations to monitor the health of these systems and provide reports of problems.It can update the embedded software in these systems.In the event of system problems,this system can also be used to remotely control a wildern
45、ess weather system.In Figure 11-2,I have used the UML package symbol to indicate that each system is a collection of components and have identified the separate systems,using the UML stereotype system.The associations between the packages indicate there is an exchange of information but,at this stag
46、e,there is no need to define them in any more detail.Figure 11-3 is an example of a sequence model,shown as a UML sequence diagram.This diagram shows the sequence of interactions that take place when an external system requests the summarized data from the weather station.You read sequence diagrams
47、from top to bottom:1.The SatComms object receives a request from the weather information system to collect a weather report from a weather station.It acknowledges receipt of this request.The stick arrowhead on the sent message indicates that the external system does not wait for a reply but can carr
48、y on with other processing.2.SatComms sends a message to WeatherStation,via a satellite link,to create a summary of the collected weather data.Again,the stick arrowhead indicates that SatComms does not suspend itself waiting for a reply.Figure 11-3 Sequence diagram describing data collection3.Weathe
49、rStation sends a message to a Commslink object to summarize the weather data.In this case,the squared-off style of arrowhead indicates that the instance of the WeatherStation object class waits for a reply.4.Commslink calls the summarize method in the object WeatherData and waits for a reply.5.The w
50、eather data summary is computed and returned to WeatherStation via the Commslink object.6.WeatherStation then calls the SatComms object to transmit the summarized data to the weather information system,through the satellite communications system.11-2 Reading Material 11-2-1 Reading comprehensionSoft
