1、Software Engineering CSE470: Cheng and McUmber,1,Software Engineering CSE470(Fall 2001),Instructors: Dr. B. Cheng (Sect. 1-3) Dr. W. McUmber (Sect. 4-6),2,Software Engineering CSE470: Cheng and McUmber,Acknowledgments,G. Coombs L. Dillon M. Heimdahl R. Stephenson National Science Foundation: VESL (V

2、isions of Embedded Systems Laboratory) CDA-9700732 Tony Torre, Detroit Diesel Corp.,3,Software Engineering CSE470: Cheng and McUmber,What is Software Engineering ?,The study of systematic and effective processes and technologies for supporting software development and maintenance activities Improve

3、quality Reduce costs,4,Software Engineering CSE470: Cheng and McUmber,Historical Perspective,1940s: computers invented 1950s: assembly language, Fortran 1960s: COBOL, ALGOL, PL/1, operating systems 1969: First conference on Software Eng 1970s: multi-user systems, databases, structured programming,5,

4、Software Engineering CSE470: Cheng and McUmber,Historical Perspective (cont.),1980s: networking, personal computing, embedded systems, parallel architectures 1990s: information superhighway, distributed systems, OO 2000s: virtual reality, voice recognition, video conferencing, global computing, .,6,

5、Software Engineering CSE470: Cheng and McUmber,Hardware Costs vs Software Costs(% of overall costs),s/w costs,h/w costs,7,Software Engineering CSE470: Cheng and McUmber,Why is software so expensive?,Hardware has made great advances But, software has made great advances . Do the least understood task

6、s in software When task is simple Strive for Fan-in as depth increases Keep scope effect of a module within scope of control of that module effect of module should be in deeper nesting Evaluate module interfaces: Reduce complexity Reduce redundancy Improve consistency,49,Software Engineering CSE470:

7、 Cheng and McUmber,Design Heuristics (contd),Define predicatable functions for modules, but not too restrictive: Black box modules are predictable Restricting module processing to single subfunction (high cohesion) High maintenance: if randomly restrict local data structure size, options within cont

8、rol flow, or types of external interface Single-entry-single-exit modules: Avoid Pathological Connections Enter at top, exit at bottom Pathological connection: entry into middle of module Package SW based on design constraints and portability requirements Assemble SW for specific processing environm

9、ent Program may overlay itself in memory reorganize group modules according to degree of repetition, access frequency, and interval of calls Separate out modules only used once.,50,Software Engineering CSE470: Cheng and McUmber,Design Postprocessing,After Transaction or transform analysis: complete

10、documentation to be included as part of architectural design Processing narrative for each module Interface description for each module Definition of local and global data structures Description of all design restrictions Perform review of preliminary design optimization (as required or necessary),5

11、1,Software Engineering CSE470: Cheng and McUmber,Design Optimization,Objectives: Smallest number of modules (within effective modularity criteria) Least complex data structure for given purpose Refinement of program structure during early design stages is best Time-critical applications may require

12、further refinements for optimizations in later stages (detailed design and coding),Software Engineering CSE470: Cheng and McUmber,52,Embedded Systems Introduction,53,Software Engineering CSE470: Cheng and McUmber,What is an Embedded System?,Definition of an embedded computer system: is a digital sys

13、tem. uses a microprocessor (usually). runs software for some or all of its functions. frequently used as a controller.,54,Software Engineering CSE470: Cheng and McUmber,What an embedded system is NOT.,Not a computer system that is used primarily for processing. Not a software system on a PC or Unix

14、box. Not a traditional business or scientific application.,55,Software Engineering CSE470: Cheng and McUmber,Examples of Embedded Systems,56,Software Engineering CSE470: Cheng and McUmber,Why embedded?,Because the processor is inside some other system. A microprocessor is embedded into your TV, car,

15、 or appliance. The consumer does not think about performing processing, Considers running a machine or making something work.,57,Software Engineering CSE470: Cheng and McUmber,Special Characteristics,hardware and software (in one system),sensors and actuators (for inputs and outputs),synchronization

16、 (this process must complete before this process begins),timing (often real time),concurrency (several processes working at same time),58,Software Engineering CSE470: Cheng and McUmber,How are embedded systems different than traditional software?,Responding to sensors (Was this button pushed?) Turni

17、ng on actuators (Turn on power to the boiler.) Real-time (Respond to temperature change within 3 seconds.),59,Software Engineering CSE470: Cheng and McUmber,Differences between ES and traditional software development,Not dealing with only sequential code. Routine can stop at completion or in respons

18、e to an external event. Many parts of system might be running concurrently. Safety-critical component of many systems.,60,Software Engineering CSE470: Cheng and McUmber,Small and Many!,Most embedded systems use 4-, 8-, or 16-bit processors. 32-bit used for intensive applications like printer control

19、s. 8-bit processors have about 64K of memory, that limits amount of code. “By 1990 a total of about 45 million recognizable computers (i.e., PCs, Macintosh, even CP/M systems) were in place. Yet over 1 billion microprocessors and microcontrollers were shipped in that year alone!” Ganssle, J. The Art

20、 of Programming Embedded Systems Academic Press, 1992, San Diego, Cal.,61,Software Engineering CSE470: Cheng and McUmber,hardware or software ?,Where to place functionality? ex: A Sort algorithm Faster in hardware, but more expensive. More flexible in software but slower. Must be able to explore the

21、se various trade-offs: Cost. Speed. Reliability. Form (size, weight, and power constraints.),62,Software Engineering CSE470: Cheng and McUmber,hardware/software Codesign orCodesign,Model the hardware and the software system in a unified approach. Use similar design models. Need for model continuity

22、spanning levels of the design process.,63,Software Engineering CSE470: Cheng and McUmber,Traditional Embedded System Development Approach,Decide on the hardware Give the chip to the software people. Software programmer must make software fit on the chip and only use that hardwares capabilities.,64,S

23、oftware Engineering CSE470: Cheng and McUmber,Increased Complexity,Systems are becoming more and more complex. Harder to think about total design. Harder to fix bugs. Harder to maintain systems over time. Therefore, the traditional development process has to change,65,Software Engineering CSE470: Ch

24、eng and McUmber,Less Time to Develop,In embedded electronics, the total design cycle must decrease. Historically, design for automotive electronic systems takes 3-5 years to develop. Must become a 1-3 year development cycle. Must still be reliable and safe. B. Wilkie, R. Frank and J. Suchyta - Motor

25、ola Semiconductor Products Sectors, Silicon or Software: The Foundation of Automotive Electronics, IEEE Vehicular Tech., August 95.,66,Software Engineering CSE470: Cheng and McUmber,Solutions to Complexity:,Need to keep design process abstract for a longer period of time. Decomposable hierarchy (obj

26、ect-oriented). Reuse previous designs: When a design changes, reuse similar sections. Dont throw away last years design and start from scratch! Automated verification systems.,67,Software Engineering CSE470: Cheng and McUmber,Example: Fly-by-Wire Airplane,How would you start to think about developin

27、g this complex/large system? What are potential problems with deciding on the hardware right away? What are possible concurrent systems needs? What type of timing constraints might be needed?,68,Software Engineering CSE470: Cheng and McUmber,Fly-by-Wire Airplane Continued,What would be the sensors a

28、nd actuators of this system? How concerned should developers be about the safety of the system? Would testing be enough?,Software Engineering CSE470: Cheng and McUmber,69,Intentionally Blank,Software Engineering CSE470: Cheng and McUmber,70,The Problems with Software Engineering,Where do we go wrong

29、? The UML lecture notes are based in part on those developed originally by Mats PE Heimdahl,71,Software Engineering CSE470: Cheng and McUmber,Common Problems,The requirements are wrong Incomplete, inconsistent, or ambiguous The developer and the customer did not interpret the requirements the same w

30、ay Requirements drift The requirements tend to change throughout the project Late design changes,Continual change The functionality of the system continually changes Many changes come late in the project Many changes during maintenance Breakdown of system structure The system finally becomes unusabl

31、e,72,Software Engineering CSE470: Cheng and McUmber,Solutions,Rigorous requirements and planning stage Make sure all stakeholders understand and agree on the requirements Structure the system design to accommodate change Isolate parts that are likely to change Modularize so changes are contained Att

32、empt to not compromise system structure during change,73,Software Engineering CSE470: Cheng and McUmber,Use-Cases and Scenarios,A powerful approach to find out what the requirements on the system are Helps the analysts identify The various users of the system Humans, software, and machines The funct

33、ions the system must provide Provide more stable requirements,Software Engineering CSE470: Cheng and McUmber,74,Intentionally Blank,Software Engineering CSE470: Cheng and McUmber,75,Intentionally Blank,Software Engineering CSE470: Cheng and McUmber,76,Object-Oriented Development,77,Software Engineer

34、ing CSE470: Cheng and McUmber,Structure the system based on the structure of the problem domain, NOT based on the structure of the solution,The OO Solution,The problem domain is relatively constant Creating cards Assemble the card and get the right thing at the right place Auto pilot Get a plane fro

35、m point A to point B using the available control surfaces The functionality and data representation is what is likely to change Creating cards The type of information and placement of information changes often The options available to the user evolve with time Auto pilot The hardware interfaces are

36、different between different models The operational modes vary between models and evolve over time,78,Software Engineering CSE470: Cheng and McUmber,What is OO,A way of thinking about a problem (software) based on abstractions of concepts that exist in the real world OO is not constrained by implemen

37、tation language (C, Pascal, FORTRAN , etc. will work),79,Software Engineering CSE470: Cheng and McUmber,OO is not the answer to all your problems,What is not OO,Using an “object oriented” language (C+, Eiffel, Smalltalk) You can easily misuse the OO support in these languages Using an “OO notation”

38、for design Misuse the notation for a non-OO design Calling what you do OO Management and customers like OO, therefore, that is what we are doing,80,Software Engineering CSE470: Cheng and McUmber,Several Complementary Models,Structural Models Describes the structure of the objects in a system Structu

39、re of individual objects (attributes and operations) Relationships between the objects (inheritance, sharing, and associations) Clustering of objects in logical packages and on the actual hardware Dynamic models (behavioral models) The aspects related to sequencing of operations Changes to attribute

40、s and sequences of changes The control aspects of the system,Software Engineering CSE470: Cheng and McUmber,81,Intentionally Blank,Software Engineering CSE470: Cheng and McUmber,82,The OO Development Process,83,Software Engineering CSE470: Cheng and McUmber,We Will Cover,Requirements specification V

41、ery briefly Iterative development Different models Three distinct models for which you can use UML Domain (or conceptual) model Analysis (specification) model Design (implementation) model How do we move between the models,84,Software Engineering CSE470: Cheng and McUmber,Process Overview,Inception

42、Elaboration Construction Many iterations Transition,85,Software Engineering CSE470: Cheng and McUmber,Inception,Creation of the basic idea that we want to implement (presumably with software) Could take many shapes A discussion over a beer at the pub A full fledged feasibility study Figure out (roug

43、hly) The business case How much money will this make the company Project scope,86,Software Engineering CSE470: Cheng and McUmber,Elaboration,Answer the following: What is it you are going to build? How are you going to build it? What technology are you going to use? Your decisions should be guided b

44、y the risks Requirements risks Technological risks Skills risks Political risks,87,Software Engineering CSE470: Cheng and McUmber,Requirements Risks,Poor or wrong requirements a serious problem Use UML notations to help you understand the customers requirements and the inherent structure of the prob

45、lem domain Use-case diagrams and use cases to understand customer requirements Class diagrams, activity diagrams, and possibly other diagrams to understand the domain,88,Software Engineering CSE470: Cheng and McUmber,Plan the Construction Phase,We will never build the entire system at once Increment

46、al development Categorize the use cases “I absolutely must have this function in the system” “I can live without this feature for a little while” “This is an important function, but we might be able to live without it” Time estimate and allocate the use cases to iterations,89,Software Engineering CS

47、E470: Cheng and McUmber,Construction,Construct the system as a series of iterations Each iteration is a “mini” project Analyze the use case, design, code, test, and integrate. Refine your domain model Identify all attributes and operations Define the dynamic behavior of all objects State machines “C

48、ontracts” Make decisions influenced by platform and language,90,Software Engineering CSE470: Cheng and McUmber,Transition,The phase between the beta release and the final product Wrap up all the issues that should not be done or cannot be done during the iterations Examples include performance evalu

49、ation and optimization Complete system testing No new functionality added Fix bugs Refactor your system a final time,91,Software Engineering CSE470: Cheng and McUmber,Three Distinct Models,A conceptual model (domain model) Try to figure out what is really going on Build a model to better understand

50、the problem Used to communicate with the customer and “domain” experts An analysis model (specification model) Model the software that will implement the system Focus on the software structure and the module interfaces Design model (implementation model) A detailed design of the software Including a

51、ll attributes and detailed descriptions of the operations,92,Software Engineering CSE470: Cheng and McUmber,Summary,Inception Elaboration Construction Many iterations Transition,Software Engineering CSE470: Cheng and McUmber,93,Intentionally Blank,Software Engineering CSE470: Cheng and McUmber,94,Us

52、e Cases and Scenarios,95,Software Engineering CSE470: Cheng and McUmber,We Will Cover,What is a use-case Use-case versus user interaction Use-Case diagrams The constructs in the use-case diagrams Capturing the use-case High-level use-case Extended use-case Difference between use case and scenario,96

53、,Software Engineering CSE470: Cheng and McUmber,What is a Use-Case,A use-case captures some user visible function This may be a large or small function Depends on the level of detail in your modeling effort A use-case achieves a discrete goal for the user Examples Format a document Request an elevat

54、or How are the use cases found (captured or elicited)?,97,Software Engineering CSE470: Cheng and McUmber,User Goals versus User Interactions,Consider the following when formatting a document Define a style Change a style Copy a style from one document to the next versus Format a document Ensure cons

55、istent formatting of two documents The latter is a user goal Something the user wants to achieve The former are user interactions Things the user does to the system to achieve the goal,98,Software Engineering CSE470: Cheng and McUmber,Goals and Interactions,There is a place for both goals and intera

56、ctions Understand what the system shall do Capture the user goals Understand how the user will achieve the goals Capture user interactions Sequences of user interactions Thus, start with the user goals and then refine the user goals into several (many) user interactions,99,Software Engineering CSE47

57、0: Cheng and McUmber,Use-Case Diagrams (POST),Adapted from Larman “Applying UML and Patterns”,POST: Point of Sale Terminal,100,Software Engineering CSE470: Cheng and McUmber,Another Example,Adapted from Fowler “UML Distilled”,Financial Trading System,101,Software Engineering CSE470: Cheng and McUmbe

58、r,Uses and Extends,Includes You have a piece of behavior that is similar across many use cases Break this out as a separate use-case and let the other ones “include” it Examples include Valuation Validate user interaction Sanity check on sensor inputs Check for proper authorization,Extends A use-cas

59、e is similar to another one but does a little bit more Put the normal behavior in one use-case and the exceptional behavior somewhere else Capture the normal behavior Try to figure out what can go wrong in each step Capture the exceptional cases in separate use-cases Makes it a lot easier to understand,102,Software Engineering CSE470: Cheng and McUmber,Includes,You have a piece of behavior that is similar across many use cases Break this out as a separate use-case and let the other ones “include” it Examples include Valuation Validate user interaction Sanity chec