Course Summary: Review of Software Engineering Requirements and Architecture Gruia-Catalin Roman and Christopher Gill CSE 436 Spring 2007 Department of Computer Science and Engineering.
Download ReportTranscript Course Summary: Review of Software Engineering Requirements and Architecture Gruia-Catalin Roman and Christopher Gill CSE 436 Spring 2007 Department of Computer Science and Engineering.
Course Summary: Review of Software Engineering Requirements and Architecture Gruia-Catalin Roman and Christopher Gill CSE 436 Spring 2007 Department of Computer Science and Engineering Costs The cost of correcting an error grows very rapidly as the project moves along its life-cycle This observation argues for early error detection and provides the motivation for technical reviews error correction cost point of detection The highest cost errors are those involving the systems requirements formulation [ §1 : 2 ] Response There is no silver bullet for the very difficult task of requirements definition and management The state of the art, however, is very much ahead of the state of the practice What you learn in this course, you can apply with impact A standardized framework can be the conduit for bridging the gap increased awareness common terminology assimilation of very basic practices [ §1 : 3 ] Motivation Premise of modern software engineering design/planning must consider product’s entire life this is a central and essential assumption In contrast, a more narrow perspective e.g., development only is likely to lead to failures lacks dependability assurances risks later expenses much > development costs [ §1 : 4 ] Waterfall Model of System Lifecycle Understanding requirements presupposes a good grasp of the development process as a whole Waterfall model remains one of the best abstractions for the entire development process Requirements def inition Sy stem design Sof tware design Implementation and unit testing Integration and testing Operation and maintenance [ §1 : 5 ] Requirements in Context Requirements may vary System requirements result from an analysis or discovery process Software requirements in level of abstraction, contents from one context to another result from a design process involving requirements allocation Sometimes there is no distinction between them constraints problem needs Requirements def inition system requirements Sy stem design software requirements Sof tware design [ §1 : 6 ] Terminology A requirement is a technical objective which is imposed upon the software, i.e., anything that might affect the kind of software that is produced A requirement may be imposed by the customer the developer the operating environment The source, rationale, and nature of the requirement must be documented Requirements fall into two broad categories functional non-functional [ §1 : 7 ] Communication Issues Missing or vague requirements are a recipe for disaster Anything that is not made explicit may not be implemented or considered Anything that is ambiguous is likely to get implemented in the least desirable way Standard trade practices may be omitted (in principle!) Cultural settings do affect the way in which requirements are written and read Multiple views may be required to formulate a reasonably complete set of requirements [ §1 : 8 ] Functional Requirements Functional requirements are concerned with what the software must do capabilities, services, or operations Functional requirements are not concerned with how the software does things, i.e., they must be free of design considerations Functional requirements are incomplete unless they capture all relevant aspects of the software’s environment they define the interactions between the software and the environment the environment may consist of users, other systems, support hardware, operating system, etc. the system/environment boundary must be defined [ §1 : 9 ] What Constitutes “Functional”? Type as input, value as output Type as input and output E.g., towards functions and operators Value as input, type as output E.g., towards allowed polymorphism and type conversions Value as input and output E.g., towards constructors and initialization methods E.g., towards classifiers and type identifiers … combinations of these kinds of domains/ranges [ §1 : 10 ] Non-Functional Requirements Non-functional requirements place restrictions on the range of acceptable solutions Non-functional requirements cover a broad range of issues interface constraints performance constraints operating constraints life-cycle constraints economic constraints political constraints manufacturing [ §1 : 11 ] What about Time? Superficially, time seems (and often may be) non-functional However, some systems are inherently time-dependent E.g., human interaction, mechanical control, etc. Making system run too much faster or slower may be harmful In such cases, time must be treated as a functional element One technique is to transform time into events E.g., when running faster is “a good thing” but does not change outcome A timer or other device has a specified setting (e.g., rate) : Τ The device generates events at times governed by that setting : f(Τ) Functional requirements can be written about Τ and f(Τ) Per a model that represents the relationship between Τ and f(Τ) [ §1 : 12 ] Elicitation Discover and catalogue application needs Identify constraints Identify and prioritize objectives Reconcile conflicting views Define standard terminology Separate concerns Organize the information Pave the way to conceptualization Make technical specifications feasible [ §1 : 13 ] Principal Product of Elicitation Requirements Definition Document (RDD) is still at a relatively high level does not provide yet a baseline for the development (needs to be refined and extended during specification) does provide the basis for specification is the starting point for a number of specialized preliminary studies The document must be accessible to a broad range of readers customers, users, managers, designers [ §1 : 14 ] Sample RDD Table of Contents 1. Introduction - the mind set 2. Definition of terms - the basis for accurate communication 3. Objectives - the central issue 4. Overall system organization - the context 5. External Interfaces - the environment refined 6. Capabilities - the outline for a solution 7. Constraints - the bounds placed on the solution space 8. Additional documentation - attached or included by reference [ §1 : 15 ] Software Requirements Specification (SRS) Point of origin Purpose elicitation and/or allocation activity provide a baseline for all software development activities Focus software/environment interactions technical reformulation of constraints Nature highly technical Usage design testing technical studies [ §1 : 16 ] Sample SRS Table of Contents 1. Introduction 2. General description 3. Specific requirements (ANSI/IEEE STD-830-1984) 3.1 Functional requirements - input/processing/output 3.2 External interface requirements - interface specification 4. Performance requirements (non-functional) 5. Design constraints 6. Attributes 7. Other requirements [ §1 : 17 ] Traceability Objectives, capabilities, and constraints in the RDD are traceable to the SRS having to trace the lesstechnical RDD to design can become counterproductive one objective may affect everything Using the RDD only to construct the SRS is feasible for some projects RDD SRS objectives and rationale should not be lost DESIGN [ §1 : 18 ] Traceability Traceability is a property of the software development process Specifications may be refers to the ability to relate elements of a specification to those design components that ensure their satisfiability relations that are precise and narrow in scope simplify analysis relations that are diffused often entail complex analysis functional or non-functional part of the system requirements or the byproduct of design Traceability is a useful tool, but not a substitute for verification Most traceability chains run through the software architecture requirements to design design to code [ §1 : 19 ] Requirements Verification Requirements verification is an activity directed towards the discovery of specification errors The ultimate goal is to ensure that the specification (when considered on its own) is correct consistent complete The verification must be carried out against a model (formal or informal) Formal and semi-formal specifications can be checked out by tools [ §1 : 20 ] Verification Example: Elevator Door Control Logic Consider a deterministic finite state representation of the elevator movement logic Some errors can be detected simply by the nature of the model invalid initial state missing transitions non-deterministic transitions possible live-lock, etc. down mov ement floor j arrived f loor sensor input door open request f rom this f loor and none f or other f loors timeout with no requests door closed request f or some other f loor departed down mov ement [ §1 : 21 ] Requirements Validation Concerned with establishing that specified requirements represent the needs of the customer and/or user Needs are not reflected by any model or document Thus, validation cannot be performed in a mechanical way Good communication is the key to a successful validation well-defined terminology well-written and simple specifications formal reviews rapid prototypes simulations [ §1 : 22 ] Validation Example: Elevator Movement Policy Consider an elevator movement policy which The policy satisfies the customer stated requirements takes the elevator up and down, from top to bottom, and services requests as it goes every request is eventually serviced there is a defined upper bound on the time it takes for a request to be serviced Nevertheless the time it takes to service a request during low demand periods may be unacceptable unnecessary energy utilization emerges as a new issue the need for a better policy (and ideas about it) may emerge [ §1 : 23 ] Requirement Specification & Testing: Domain Specific Scripting Languages Readable, approachable language 1. aircraft.extend_flaps 2. create_threat “MIG29”, :distance => 3.miles In contrast to… 1. aircraft.digital_inputs[FLAPS] = 2; 2. threat_environment->addThreat(new ThreatAircraft(MIG_29, aircraft.altitude, position_offset(aircraft.latitude,aircraft.longitud e,aircraft.bearing,3*MILES_TO_FEET))); (Thanks to John Aughey for this slide) [ §1 : 24 ] State Machine Models External actions associated with transitions push ——— unlock heating high ——— yellow off ready push ——— lock high ——— heater off red light low ——— heater on green light low ——— yellow push ——— unlock Documentation implications 3. Specific Requirements 3.1 Initial state Initialization 3.2 State A 3.2.1 Event X Next State S’ Action A cooling [ §1 : 25 ] Object-Oriented Variations Events may be external or internal (conditions) Actions may be external or internal (operations) ev ents Finite State Controller external object actions external object system objects [ §1 : 26 ] Data Flow Models Dataflow diagram notation functions—deterministic input/output transformations triggered by the presence of all needed inputs flows—unbounded queues stores—global system data terminators—interface models minispecs—semantics of the lowest level functions operator verify customer customer file phone order update customer data customers item mailing address update stock item profile inventory order prepare order shipping [ §1 : 27 ] User Manual For Applications Involving Human Interfaces Effective specifications often require the integration of multiple related models Human/computer interactions are too complex for commonly used requirements techniques The User Manual can be used as a substitute for (and/or can grow out of) large sections of the SRS [ §1 : 28 ] User Interface Navigation Identify the screens/windows Define permitted transitions among them as a graph Identify the events that trigger moves from one screen/window to another Identify interactions common among screens/windows specific to the user interface paradigm in use [ §1 : 29 ] Use Case Models Actors model the environment and the users initiate activity by providing stimuli can be primary or secondary Use cases are complete courses of action initiated by actors (basic or alternative) can be extended by (interrupt analogy) or use other use cases (call analogy) authorization uses phone call extends charging [ §1 : 30 ] Architecture Design Phase Technical goals Identify the principal components that make up the system and their (internal and external) interfaces Ensure compliance with respect to expectations captured in the requirements specification Understand, assess, and control risks Ensure predictability of the development process through accurate planning [ §1 : 31 ] Software Architecture as Artifact The architecture of a system is an abstract description of its structure and behavior The level of abstraction is chosen such that all critical design decisions are apparent and meaningful analysis is feasible A complete software architecture is usually specified by a combination of design diagrams component specifications [ §1 : 32 ] Hierarchy and Partition Water tank example Heat Controller Controller Water Tank Tank Timer Intake Heater Outtake [ §1 : 33 ] Many Architectural Styles Composition layered controller client/server pipes and filters peer to peer proxy / object-based Communication static object-oriented software bus service provision implicit message passing event propagation Coordination dynamic explicit blackboard shared tuple space database/futures Emerging styles new software domains mobile computing sensor networks [ §1 : 34 ] Design Diagrams An abstraction of the system structure A map of the system organization at a particular level of abstraction Names of the principal system components and relations among them Hints at the operational behavior of the system (constrains what the system can do) May provide implementation directives [ §1 : 35 ] Component Specifications Component specifications supply the details needed to provide a complete system description at this particular level of abstraction interface syntax interface semantics The structural and behavioral properties captured by the component specifications must be consistent with the design diagram [ §1 : 36 ] Alternative Decomposition Approaches Function-oriented modularity Synonyms: action, process, transformation Basic idea: organize the system structure around the kinds of activities it must perform Rationale: a system is the functionality it supplies to the user Object-oriented modularity Synonyms: data record, class Basic idea: organize the system structure around the kinds of data it must maintain Rationale: functionality changes more often than the data required to support it [ §1 : 37 ] An Example of Component Notation Passive object task active object task active object Organizational procedure Active procedure object package External package devices and interfaces [ §1 : 38 ] Object Level Synchronization The notation is the same for classes and objects and so are the semantics Synchronized objects specify mutual exclusion among all methods @ class method 1 method 2 method 3 Notation and semantics may be adjusted for different settings Synchronized methods limit mutual exclusion to identified methods class @ method 1 @ method 2 method 3 [ §1 : 39 ] Component Sample component types procedure object process (threaded object) Interface depends on component type and language—but it is real Behavior reflects the component type but must be abstract Heater Methods turn on, turn off failed, heating State Heat Controller Heater active (T/F) failed (T/F) h = 1..4 turn off failed inactive turn on active [ §1 : 40 ] Connector Sample connector types procedure invocation message queue Connectors are complex specialized components Heat Controller Heat Controller vs. Heater Possible alternatives Heat Controller method invocation message passing event notification Heat Controller raise heater on send get Heater h = 1..4 Heater h = 1..4 Heater h = 1..4 [ §1 : 41 ] Sample Connectors messag e queue intruder water field condition auto watering manual watering timer sprayer ph sensor loss incident logging sensor field bus [ §1 : 42 ] Actuator Actuators are events of Heat Controller a predefined nature that Some methods are time initiate activity triggered timer interrupt Implementation is mouse down language specific often complex distributed across the code heater duty cycle is at the level of 100 milliseconds Heat Controller Conceptually are simple to understand easy to analyze Heater h = 1..4 [ §1 : 43 ] Modular Design elevator control door manager alignment manager door assembly alignment sensor travel manager main motor floor sensor [ §1 : 44 ] Responsive Design Continuous alignment while at a floor elevator control door manager alignment manager door assembly alignment sensor travel manager main motor floor sensor [ §1 : 45 ] Safe Design Doors are closed while moving or not at a floor elevator control door manager doors closed stationary level at floor travel manager mandatory check door door assembly floor departure request alignment sensor floor edge up floor sensor edge down main motor [ §1 : 46 ] Concluding Remarks Development of software based systems is complex multiple perspectives different notations significant and sophisticated analysis Requirements elicitation and specification should focus on communication among people Requirements must be traceable through the architecture to the code itself (and vice versa) The design process should focus mainly on fundamentals and on the creative activities [ §1 : 47 ]