Software Engineering Midterms PDF

Requirements Analysis Prototyping User Requirements Prototype - description of what services that system is expected - concrete model of how a system will appear or to provide...

Requirements Analysis Prototyping User Requirements Prototype - description of what services that system is expected - concrete model of how a system will appear or to provide behave - constraints under which it must operate - usually depict the user interface - can be classified according to fidelity: System Requirements Low Fidelity - detailed information about the system functions, - paper services, and operational constraints that are to be High Fidelity implemented - GUI Functional Requirements When Might Prototyping be Done? - statements of the services that a system should 1) Before the Beginning provide - to show proof of concept to senior - how the system should behave in particular situations management 2) In the Beginning Non-Functional Requirements - to gather initial user requirements - constraints on the services or functions offered by the 3) After the Beginning system - to validate evolving user requirements - normally apply to the system as a whole 4) During the Middle Stages - timing, performance, reliability, development - to validate system specifications process, standards 5) After the Middle Stages - to pre-train users or to create marketing Characteristics of Requirements: demos Unambiguous 6) In the Later Stages Complete - to explore solutions to usability or design Consistent (Company Goals, System Objectives, etc.) problems Traceable Realistic Types of Prototyping: Verifiable 1) Paper Valid - drawings, cutouts - elicits user interface content organization Requirements Engineering Activities: - easy to annotate 1) Feasibility Study 2) Wizard of Oz - assess whether the proposed system is viable - person simulates computer's behavior and worth pursuing - explores interactivity 2) Requirements Elicitation and Analysis - can be used as an interviewing technique - gather requirements from stakeholders and 3) Mockup understand the system's needs - non-functional user interface layout using 3) Requirements Specification actual GUI - document the system’s requirements in a - components clear, consistent, and complete manner - validates UI design 4) Requirements Validation - aids in refining look and feel - ensure the requirements meet the needs of 4) Working/Functional stakeholders and are feasible - mockup with functional GUI components - validates design REQUIREMENTS ELICITATION AND ANALYSIS: - explores interaction issues such as timing - demonstrates progress Problems/Difficulties: 5) Throwaway Prototyping Stakeholders don’t know what they want - creation of a simple working model of Stakeholders express requirements in their own terms system to show users what requirements Different stakeholders may have conflicting may look like when implemented requirements - requirements can be identified, simulated, Organizational and political factors may influence the and tested more quickly system requirements - leads to the accurate specification of The requirements change during the analysis process - requirements, and the construction of a valid and useable system Activities: 6) Evolutionary Prototyping Discovery - main goal is to build a very robust prototype Classification and Organization in a structured manner and constantly refine Prioritization and Negotiation it Documentation - improvements and further requirements are built on the existing prototype Classic Elicitation Techniques: - makes use of functional prototypes Interviews Research Advantages of Prototyping: Questionnaires Reduces development time and cost Observation Effective tool for building good HCI Forms Analysis  Builds confidence in the customer that the developer can produce a system Problems with Natural Language Specification: Energizes customer/developer communication 1) Ambiguity Facilitates system implementation - prone to different interpretations Higher user satisfaction 2) Over-Flexibility Improves decisions by providing alternatives - different ways of stating the same thing Exposes developers to future enhancements 3) Lack of Modularization - inadequate to structure requirements Disadvantages of Prototyping: Can focus design on aesthetics rather than System Requirements functionality - are better represented with more specialized notation False impression that system will be easy to build Customer may view shortcomings of prototype as 1) Graphical Models flaws - process models, sequence diagram, data Developers can become too attached to their models prototypes 2) Tables Time saving benefit can be lost when developing - used to summarize and present data, sophisticated prototypes requirements, or relationships in a structured A working prototype may be put into production and easy-to-read format 3) Structured Language Other Discovery Approaches: - freedom of writer is limited by a predefined 1) Viewpoints template - way of structuring requirements to represent - imposes a standard and a degree of perspective of different stakeholders uniformity - limits the terminology that may be used Interactor Viewpoint - maintains the expressiveness of natural - people or systems that interact directly with language the system 4) Form-based - definition of the function or entity Indirect Viewpoint - description of inputs and where they come - stakeholders who influence the requirements from (e.g., management) - description of outputs and where they go to - indication of other entities required Domain Viewpoint - pre and post conditions (if appropriate) - domain characteristics and constraints that - the side effects (if any) of the function influence the requirements (e.g., law) 5) Analysis Models - graphical representations - that describe the business process and the 2) Scenarios system to be developed; serve as a bridge - real-life examples of how a system can be between analysis and design used context models Description of the normal flow of data-flow models events state-machine models Description of what can go wrong data models Information about other concurrent object models activities 6) Software Requirements Specification (SRS) Description of the state when the - official statement of system requirements scenario finishes - represents WHAT the system should do, not HOW it should be done 3) Use Cases - complete specification may include the SRS, - normalized way to document system models and the prototype functionality from the user’s perspective 7) IEEE Requirements Standard - describes a goal-oriented interaction - defines a generic structure for a between an actor and the system requirements document Introduction Work Products After Requirements Elicitation: General description Statement of need and feasibility Specific requirements Bounded statement of scope Appendices List of stakeholders Index Description of the technical environment 8) Sample Structure List of requirements (preferably organized by Preface function) Introduction Prototypes developed to better define requirements Glossary User Requirements Definition Requirements Specification System Architecture - process of documenting the functional and System Requirements Specification non-functional requirements of a system System, Models Appendices User Requirements Index - typically stated in natural language Requirements Validation change - assessment of the quality of the requirements Technical reviews or design walkthroughs should be (checked against characteristics) conducted to minimize semantic errors and assess - determines whether the requirements actually design quality - define what the customer wants Design must be a readable, understandable guide for - check for inconsistencies, omissions and errors those who will generate code and those who will test - techniques the software Specification reviews Prototyping Test case generation Key Design Techniques: 1) Abstraction Requirements Management - helps simplify the complexity of a system by - process of identifying, understanding, tracking and focusing on the essential aspects controlling changes to system requirements 2) Decomposition and Modularization - requirements are inevitable incomplete and - enable systems to be broken down into inconsistent manageable parts new requirements emerge 3) Encapsulation/ Information Hiding priority of requirements may change - protects the internal workings of (business environment change, technical components from outside interference environment change, better understanding of 4) Defined Interfaces the system) - allow components to interact without system customers and end-user requirements knowing each other’s internal details may conflict 5) Low Coupling and High Cohesion Requirements Management Planning: Low Coupling Requirements Identification - modules are relatively independent of each Change management process other, which makes them easier to maintain, - focused on the impact and cost of changes test, and understand Traceability Policies ○ keep sufficient amount of information about High Cohesion ○ requirements relationships - ensure that a module is easy to understand, ○ Types of Traceability: maintain, and reuse, as it performs a clearly Source defined set of tasks Dependency Features or Design (represented Some Key Design Issues: using 1) Concurrency CASE Tool Support - main concurrent activities? - how is their interaction managed? 2) Workflow and Event Handling - activities inside a workflow? Software Design - how are events handled? 3) Distribution Design - how is the system distributed physically - first step in the development phase for any (and virtually)? engineered product or system 4) Error handling and Recovery - process of applying various techniques and principles - what is the system behavior when failure for the purpose of defining a device occurs? - process or system in sufficient detail to permit its - how are exceptional circumstances handled? physical realization 5) Persistence of data - which data needs to persist? Software Design - how complex is the data? - iterative process through which requirements are translated into a “blueprint” for building software Design Process - multistep process in which representation of data - involves several stages that translate requirements structure, program structure, interface characteristics into a blueprint for building the system and procedural detail are synthesized from the Architectural Design requirements Interface Design - process of defining the software architecture, Component Design components, modules, interfaces, and data for a Data Design software system to satisfy specified requirements Algorithm Design Design Principles: Overall Design Strategy may Vary: Design process should not suffer from tunnel vision 1) Function-Oriented Design should be traceable to analysis (implement - traditional approach where the explicit and implicit requirements) system is decomposed into a set of Design should “minimize the intellectual distance” interacting functions between the software and the real world problem 2) Data-Oriented Design should exhibit uniformity and integration - focuses on how data is structured, Design is not coding, coding is not design stored, and managed within the Design should be structured to accommodate system  3) Object-Oriented - creating reusable components that 4) Blackboard model real-world entities and - variation of the repository model: interactions Knowledge Sources Architectural Design - components that provide - establishes a basic structural framework that application dependent knowledge identifies the major components of system and the Blackboard communication among these components - a shared repository of problems, - focuses on architectural issues: partial solutions, suggestions, and control structure contributed information protocols for communication Control Shell synchronization and data access - controls the flow of functionality and composition of design problem-solving activity in the system Objectives: Stakeholder Communication 5) Implicit Invocation Analysis - components do not explicitly invoke a ○ communication of the process understanding of the solution - a component broadcasts one or more events, ○ software engineers can make and components can register interest in such principled choices among design events by associating a procedure with the alternatives event ○ aids in complexity management Large-Scale Use 6) Process-Control - widely used for machine control Other Issues: applications and are typically modeled via System architecture is the highest level of finite state machines shared understanding of that system Ensure that the architecture is appropriate 7) Client-Server not only for the operations, but also for - system is organized as a set of services and deployment and maintenance associated servers and clients that access and Design decisions can enhance specific use these services attributes - only the servers have identities that are ○ Performance (localization of known in advance operations) - clients access the servers via remote ○ Safety (isolation of safety-critical procedure calls or SQL components - evolved from mainframe architectures and ○ Availability (include redundant file sharing architectures components) ○ Maintainability (use fine-grained, 8) Two-Tier independent components) - client-server applications that ran on a workstation but accessed data from a Architectural Styles/ Patterns: database server 1) Pipe and Filter (Pipeline) - later architectures split the application itself - component reads streams of data on its into two parts: inputs and produces streams of data on its a shared component for business outputs, delivering a complete instance of logic that ran on the server the result in a standard order local clients that implemented the - accomplished by applying a local user interface transformation to the input streams and computing incrementally so output begins 9) Multi-Tier before input is consumed - the user interface, functional process logic, data storage and data access are developed Components = Filters and maintained as independent modules, Pipes - transmit the output of a most often on separate platforms filter as inputs to another - layers: Presentation Tier 2) Layered (Abstract Machine Model) Logic Tier/ Business Logic Tier/ - organizes a system into layers, each of Transaction Tier which provide a set of services Data Tier - communication is limited to adjacent layers - layers are built up from low-level, more 10) Model-View-Controller primitive - decouples data access and business logic - behavior to high-level behavior from data presentation and user interaction via the controller 3) Repository - consists of a central data store and a set of independent components that access the data store  Model - results in reduced cost, more processing - domain-specific representation of power, scalability, improved network the information on which the technology, availability application operates - may be part of a grid View More tightly coupled - renders the model into a form Less Heterogeneous suitable for interaction Has a single system image - typically a user interface element Has a centralized job management Controller and scheduling - processes and responds to events - typically user actions, and may Categories: invoke changes on the model 1) High Availability Clusters (Failover Clusters) 11) Distributed Systems Architectures - ensure availability by - collection of autonomous computers, employing redundancy connected through a network and 2) Load-Balancing Clusters distribution middleware, presenting a - enable efficient workload unified system to users of nodes by employing - support concurrent processing and data load-balancing nodes replication for robustness, without requiring 3) High-Performance Clusters all nodes to be online at once - exploit the parallel processing power of Peer-to-Peer (P2P) multiple nodes - share resources like bandwidth and storage among equal nodes, increasing reliability Technologies and Implementations: through data replication MPI (Message Passing Interface) - common uses include file sharing, VoIP, and PVM (Parallel Virtual Machine) media streaming Beowulf Linux-HA Hybrid P2P RedHat Cluster Suite - has a server that keeps information Sun Cluster on the peers and responds to Microsoft Cluster Server requests for such information Oracle ClusterWare Grid Computing Cloud Computing - combines diverse, loosely-coupled resources - tasks are assigned to a combination of into a single large system for powerful connections, software and services accessed computing over a network (the cloud) - virtualize resources to solve problems - users can reach into a cloud for resources - utilizes idle resources (CPU, data, on- demand by using a thin client or access bandwidth) effectively points (phone/laptop) - enhances application speed, resource - may be a resource in a grid availability, and collaboration Typical Implementations: Key Components: 1) SaaS (Software as a Service) Security - cloud provides software to User Interface clients Workload Management 2) Utility Computing Scheduler - provision of storage and Resource Management virtual server for a fee Standards and Technologies: Technologies: OGSA (Open Grid Services XML Architecture) SOAP OGSI (Open Grid Services REST Infrastructure) AJAX WSRF (Web Services Resource Infrastructure) Sample Applications: CORBA 1) Google Apps NorduGrid - provides common Globus business applications GridBus online that are accessed from a Web browser Cluster Computing 2) Google App Engine - technique of linking two or more computers - platform for building and into a network (LAN) in order to take hosting web applications advantage of the parallel processing of on Google servers computers 3) AWS (Amazon Web Services) - set of web services by Amazon.com  EC2 (Amazon Elastic Compute Universal Description, Discovery, Cloud) - allows client to rent an and Integration (UDDI) arbitrary number of virtual - XML-based registry to machines to run their applications publish service descriptions (WSDL) and S3 (Amazon Simple Storage allow their discovery Service) - provides unlimited storage services XACML - a markup language for Service Oriented Architecture (SOA) expressing access control - enables the creation of applications that are rules and policies built by combining loosely coupled and interoperable services Interface Design - makes applications easily to adapt to - describes how the software communicates changing technologies and integrate with within itself, to systems that interact with it, other applications and with humans who use it Services Internal Interface - independent software components - represent the interfaces between with standard interfaces for easy modules integration - applications and services operate External Interface independently, without needing - interfaces (external data and detailed knowledge of each other’s external control) between the inner workings software and other non-human procedures and consumers of Technologies: information REST SOAP Human-Computer/ User Interface CORBA - focuses on human interaction RPC RMI User Interface Design Web Services - know the user, know the tasks Web Service User Interface Design Issues: - support machine-to-machine Correctness interaction over networks with Ease of use interfaces described in WSDL Ease of learning - systems communicate via SOAP User acceptance messages over HTTP, using XML Familiarity and Web standards (W3C) Consistency Minimal surprise (least SOAP Web Service astonishment) - all attachments (except User control binary) are carried by Memory Load SOAP Recoverability - service description is in User guidance WSDL Visualization REST Web Service “A common mistake that people make when trying to - based on the concept of a design something completely foolproof is to resource (anything with a underestimate the ingenuity of complete fools.” URL) - require little infrastructure Design Patterns except for HTTP and - provide structured solutions for recurring XML (HTTP GET, design challenges in software DELETE, POST, PUT) - describe problems and solutions abstractly, allowing reuse across various contexts Web Services Description - range from specific implementations to Language broad, system-level solutions - XML-based service description that describes Gang of Four (GoF) Patterns the public interface - design patterns were popularized - protocol bindings and by Gamma, Helm, Johnson and message formats required Vlissides to interact with a web - published work presents 23 design service patterns (in a structured format), 15 of which have wide usage  - provide a flexible Types: alternative to subclassing 1) Creational Patterns to extend functionality - initializing and 5) Facade configuring of classes and - provides a unified objects higher-level interface for 2) Structural Patterns subsystems - ways to assemble objects - interaction to a set of to realize new objects is done via the functionality façade - composition of classes and 6) Flyweight objects - use sharing to support 3) Behavioral Patterns large numbers of - dynamic interactions fine-grained objects among classes and objects efficiently - distribution of 7) Proxy responsibility - provides a placeholder for an object in order to GANG OF FOUR (GOF) PATTERNS: control access to it Creational: Behavioral: 1) Abstract Factory 1) Chain of Responsibility - factory for building related - request is delegated to the objects responsible service 2) Builder provider - used for the construction - a request can be passed of complex objects along the chain to the - the same construction object that handles it process can create 2) Command different representation - request or action as an 3) Factory Method object, which can be - defines an interface for passed, stored, activated creating an object, but let when desired subclasses decide which 3) Iterator class to instantiate - allows sequential access to 4) Prototype the elements of an - factory for cloning new aggregate without instances from a prototype exposing its representation 5) Singleton 4) Interpreter - factory for a singular - language interpreter for a (sole) instance small grammar - ensures that a class has 5) Mediator only one instance and - defines an object that provide a global point of encapsulates how a set of access objects interact and - useful when several client coordinates such objects need to refer to the interactions same object 6) Memento - snapshot captures and Structural: externalize an object’s 1) Adapter internal state so that it can - converts the interface of a be passed or restored to class into another interface this state at a later time clients expect 7) Observer - classes with incompatible - dependencies are defined interfaces can interact with to an object, so that all each other dependents update 2) Bridge automatically when an - decouple an abstraction object changes state from its implementation 8) State 3) Composite - object whose behavior - compose objects into tree depends on its internal structures state - operations apply to the 9) Strategy (sub)tree - defines a set of algorithms, 4) Decorator any one of which can be - attach additional selected across clients responsibilities to an object dynamically 10) Template Method  - lets subclasses redefine some steps of an algorithm without changing the algorithm’s structure 11) Visitor - represent operations applied to elements of an object structure Software Construction/ Implementation Implementation Concerns: 1) Complexity - ensure that details are addressed and “work around” problems in order to cope with complexity 2) Change - code should be resilient to anticipated change 3) Validation and Verification - code structure should facilitate the verification and validation process 4) Standards Compliance - ensure code adheres to established industry or project standards 5) Platform Sensitivity - design software to be compatible and optimized for different platforms Issues and Guidelines Relevant to Coding: 1) Length of Code - short does not always mean better - 30-second rule 2) Readability and Sensible Organization 3) Efficient - optimized code 4) Formatting - indentation and alignment - case conventions - white space - spaces in expressions - proper splitting a long statements across lines 5) Naming Conventions - variables, classes, class members, interfaces, packages, exceptions, etc. 6) Documentation - what and why of code - block comments vs. in-line comments - header comments 7) Variables - declare immediately before use - intermediate variables - unused variables 8) Clean Up Resources 9) Modular Programming 10) Safe and Defensive Programming 11) Coding Standards - industry (general and platform-dependent), organizational, project/product, personal END.