CEN4010 - Module 4

Architectural Style vs Architecture

-Architectural Style: A pattern for a subsystem decomposition -Software Architecture: Instance of an architectural style.

White-box testing overview

-Code coverage --Validate the line of code's execution -Branch coverage --Validate that each branch is executed (all branches in condition statements) -Condition coverage --Validates that all the conditions are executes (all choices in if statement) -Path coverage --Validates that all paths are executed. Combination of loops and decision statements.

Packages

-Packages help you to organize UML models to increase their readability -We can use the UML package mechanism to organize classes into subsystems -Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package.

UML (Unified Modeling Language)

-is a notation that resulted from the unification of OMT (Object Modeling Technique) and OOSE (Object Oriented Software Engineering). -Provides a standard notation that can be used by all object-oriented methods. -Is composed of multiple notations or diagrams: --Use Case Diagrams --Class Diagrams --Sequence Diagrams --State Chart Diagrams --Activity Diagrams

Object Modeling in Practice

1. Find New Classes 2. Review names, attributes and methods 3. Find Associations between Classes 4. Label the generic associations 5. Determine the multiplicity of the associations 6. Review associations

If we needed to use a UML diagram to model the functional behavior and the users who interact with the system, we would use the _____ diagram (choose one)

Use Case

Class Diagram: Classes

-A class represents a concept -A class encapsulates state (attributes) and behavior (operations) -Each attribute has a type -Each operation has a signature -The class name is the only mandatory information

3 Layer Architecture VS 3 Tier Architecture

-Definition: 3-Layer Architectural Style --An architectural style, where an application consists of 3 hierarchically ordered subsystems ---A user interface, middleware and a database system ---The middleware subsystem services data requests between the user interface and the database subsystem -Definition: 3-Tier Architecture --A software architecture where the 3 layers are allocated on 3 separate hardware nodes -Note: Layer is a type (e.g. class, subsystem) and Tieris an instance (e.g. object, hardware node) -Layer and Tier are often used interchangeably.

Traditional Software Lifecycle Definition (Non-Agile)

-Software lifecycle --Models for the development of software ---Set of activities and their dependency relationships to each other to support the development of a software system ---Examples: ----Analysis, Design, Implementation, Testing -Typical Lifecycle questions: --Which activities should I select when I develop software? --What are the dependencies between activities? --How should I schedule the activities?

Unit Testing

-Static Testing (at compile time) --Static Analysis --Review ---Walk-through (informal) ---Code inspection (formal) -Dynamic Testing (at run time) --Black-box testing --White-box testing.

Subsystems and Services

-Subsystem --Collection of classes, associations, operations, events and constraints that are closely interrelated with each other --In UML subsystems are modeled as packages --By decomposing a system into independent subsystems, a subsystem can be worked on by a team --The set of operations that are available to other subsystems form the subsystem interface. -Service --A set of named operations that share a common purpose -Services are defined during system design.

Nonfunctional Requirements (Questions to overcome "Writer's block")

-User interface and human factors -Documentation -Hardware considerations -Performance characteristics -Error handling and extreme conditions -System interfacing -Quality issues -System Modifications -Physical Environment -Security Issues -Resources and Management Issues

Non-Agile Approach: Waterfall Development

-Working with a Non-Agile Approach, such as the waterfall model, may be used if: --Product requires heavy and extensive documentation. --Release is not expected until the end of development. --Customers have an exact understanding of what they want. --Change is not anticipated through development.

Problems with Client/Server Architectures

Client/Server systems do not provide peer-to-peer communication

The Open Systems Interconnection model (OSI) for networking which contains multiple subsystems that communicate with the subsystem below it, is an example of a ______

Closed layered design

Continuous Testing

Continuous build: -Build from day one -Test from day one -Integrate from day one -System is always runnable Requires integrated tool support: -Continuous build server -Automated tests with high coverage -Tool supported refactoring -Software configuration management -Issue tracking.

What is the following diagram an example of? Account <-- (Current Account Savings Account)

Inheritance

Which design goal of client/server architecture means that architecture can work with an increasing number of clients?

Scalability

Pareto Principle

You can solve 80% of the modeling problems by using 20% UML

Which architectural style decouples data access from the presentation layer coordinated by a controller in a nonhierarchical fashion?

model view controller

To create a desirable system design, we want the system to exhibit ______ cohesion and _______ coupling.

high, low

Static Analysis with Eclipse

-Compiler Warnings and Errors --Possibly uninitialized Variable --Undocumented empty block --Assignment has no effect -Checkstyle --Check for code guideline violations -FindBugs --Check for code anomalies -Metrics --Check for structural anomalies

Sequence Diagrams: Creation and Destruction

-Creation is denoted by a message arrow pointing to the object -Destruction is denoted by an X mark at the end of the destruction activation --In garbage collection environments, destruction can be used to denote the end of the useful life of an object.

Nonfunctional Requirements: Examples

-"Spectators must be able to watch a match without prior registration and without prior knowledge of the match." --Usability Requirement -"The system must support 10 parallel tournaments" --Performance Requirement -"The operator must be able to add new games without modifications to the existing system." --Supportability Requirement

Example of a 4-Layer Architectural Style

-4-Layer-architectural styles (4-Tier Architectures) are usually used for the development of electronic commerce sites. The layers are --1.The Web Browser,providing the user interface --2.A Web Server,serving static HTML requests --3.An Application Server,providing session management (for example the contents of an electronic shopping cart) and processing of dynamic HTML requests --4.A back end Database, that manages and provides access to the persistent data ---In current 4-tier architectures, this is usually a relational Database management system (RDBMS).

Use Case Diagram: Extends Relationship <<extends>>

-<<extends>>relationships model exceptional or seldom invoked cases -The exceptional event flows are factored out of the main event flow for clarity -The direction of an <<extends>>relationship is to the extended use case -Use cases representing exceptional flows can extend more than one use case.

Use Case Diagram: Includes Relationship <<includes>>

-<<includes>>relationship represents common functionality needed in more than one use case -<<includes>>behavior is factored out for reuse, not because it is an exception -The direction of a <<includes>>relationship is to the using use case (unlike the direction of the <<extends>>relationship).

Properties of Subsystems: Layers and Partitions

-A layer is a subsystem that provides a service to another subsystem with the following restrictions: --A layer only depends on services from lower layers --A layer has no knowledge of higher layers --A closed layered architecture can only access the layer immediately below --An open layered architecture can access layers at deeper levels. -A layer can be divided horizontally into several independent subsystems called partitions --Partitions provide services to other partitions on the same layer --Partitions are also called "weakly coupled" subsystems.

Pipes and Filters

-A pipeline consists of a chain of processing elements (processes, threads, etc.), arranged so that the output of one element is the input to the next element --Usually some amount of buffering is provided between consecutive elements --The information that flows in these pipelines is often a stream of records, bytes or bits.

System Design: Concepts

-A subsystem is a replaceable part of the system with interfaces that encapsulate the state and behavior of its contained classes. -Coupling measures the dependencies between two subsystems. -Cohesion measures the dependencies among classes within a subsystem. -Relating Subsystems: --Layering: Hierarchy of subsystems, each providing services to the level above and below. --Partitioning: Peer subsystems -A GOOD DESIGN has high cohesion and low coupling!

Actor vs Class vs Object

-Actor --An entity outside the system to be modeled, interacting with the system ("Passenger") -Class --An abstraction modeling an entity in the application or solution domain --The class is part of the system model ("User", "Ticket distributor", "Server") -Object --A specific instance of a class ("Joe, the passenger who is purchasing a ticket from the ticket distributor").

Activity Diagrams

-An activity diagram is a special case of a state chart diagram -The states are activities ("functions") -An activity diagram is useful to depict the workflow in a system -Can model concurrency --Synchronization of multiple activities --Splitting the flow of control into multiple threads -Activities may be grouped into swimlanes to denote the object or subsystem that implements the activities.

Use Case Diagram: Actors

-An actor is a model for an external entity which interacts (communicates) with the system: --User --External system (Another system) --Physical environment (e.g. Weather) -An actor has a unique name and an optional description -Examples: --Passenger: A person in the train --GPS satellite: An external system that provides the system with GPS coordinates.

Aggregation

-An aggregation is a special case of association denoting a "consists-of" hierarchy -The aggregate is the parent class, the components are the children classes -A solid diamond denotes composition: A strong form of aggregation where the lifetime of the component instances is controlled by the aggregate. That is, the parts don't exist on their own ("the whole controls/destroys the parts")

Pipes and Filters Architectural Style

-An architectural style that consists of two subsystems called pipes and filters --Filter:A subsystem that does a processing step --Pipe:A Pipe is a connection between two processing steps -Each filter has an input pipe and an output pipe. --The data from the input pipe are processed by the filter and then moved to the output pipe

Class Diagram: Instances

-An instance represents a particular class representation -The attributes are represented with their values -The name of an instance is underlined -The name can contain only the class name of the instance (anonymous instance)

Types of Scenarios

-As-is scenario: --Describes a current situation. Usually used in re-engineering projects. The user describes the system ---Example: Description of Letter-Chess -Visionary scenario: --Describes a future system. Usually used in greenfield engineering and reengineering projects --Can often not be done by the user or developer alone ---Example: Description of an interactive internet-based Tic Tac Toe game tournament ---Example: Description -in the year 1954 -of the Home Computer of the Future. -Evaluation scenario: --Description of a user task against which the system is to be evaluated. ---Example:Four users (two novice, two experts) play in a Tic Tac Toe tournament in ARENA. -Training scenario: --A description of the step by step instructions that guide a novice user through a system ---Example:How to play Tic Tac Toe in the ARENA Game Framework.

Heuristics for finding scenarios

-Ask yourself or the client the following questions: --What are the primary tasks that the system needs to perform? --What data will the actor create, store, change, remove or add in the system? --What external changes does the system need to know about? --What changes or events will the actor of the system need to be informed about? -However, don't rely on questions and questionnaires alone -Insist on task observation if the system already exists (interface engineering or reengineering) --Ask to speak to the end user, not just to the client --Expect resistance and try to overcome it.

Associations

-Associations denote relationships between classes -The multiplicity of an association end denotes how many objects the instance of a class can legitimately reference. --1-to-1, 1-to-many, many-to-many

Requirements Specification vs Analysis Model

-Both focus on the requirements from the user's view of the system --The requirements specification uses natural language (derived from the problem statement) --The analysis model uses a formal or semi-formal notation ---We use UML (Unified Modeling Language).

Techniques to elicit Requirements

-Bridging the gap between end user and developer: --Questionnaires: Asking the end user a list of pre-selected questions --Task Analysis: Observing end users in their operational environment --Scenarios: Describe the use of the system as a series of interactions between a concrete end user and the system --Use cases: Abstractions that describe a class of scenarios.

Class Diagram

-Class diagrams represent the structure of the system -Used --during requirements analysis to model application domain concepts --during system design to model subsystems --during object design to specify the detailed behavior and attributes of classes.

Architectural Styles

-Client/Server -Peer-To-Peer -Repository -Model/View/Controller -Three-tier, Four-tier Architecture -Pipes and Filters

Sandwich Testing Strategy

-Combines top-down strategy with bottom-up strategy -The system is viewed as having three layers --A target layer in the middle --A layer above the target --A layer below the target -Testing converges at the target layer. Pros and Cons of Sandwich Testing --Top and Bottom Layer Tests can be done in parallel --Problem: Does not test the individual subsystems and their interfaces thoroughly before integration --Solution: Modified sandwich testing strategy

Requirements Elicitation: Difficulties and Challenges

-Communicate accurately about the domain and the system --People with different backgrounds must collaborate to bridge the gap between end users and developers ---Client and end users have application domain knowledge ---Developers have solution domain knowledge -Identify an appropriate system (Defining the system boundary) -Provide an unambiguous specification -Leave out unintended features

How do we find scenarios?

-Don't expect the client to be verbal if the system does not exist --Client understands problem domain, not the solution domain. -Don't wait for information even if the system exists --"What is obvious does not need to be said" -Engage in a dialectic approach --You help the client to formulate the requirements --The client helps you to understand the requirements --The requirements evolve while the scenarios are being developed

Testing: Concepts

-Failure: Any deviation of the observed behavior from the specified behavior -Erroneous state(error): The system is in a state such that further processing by the system can lead to a failure -Fault: The mechanical or algorithmic cause of an error ("bug") -Validation: Activity of checking for deviations between the observed behavior of a system and its specification. -Test Driver: Simulates part of the system that calls the component under test and passes the test input identified in the analysis. -Test Stub: Simulate a component that is called by the tested component. Must provide the same API method as the simulated component and must return a value compliant with the return signature.

How do we deal with Faults

-Fault avoidance --Use methodology to reduce complexity --Use configuration management to prevent inconsistency --Apply verification to prevent algorithmic faults --Use Reviews -Fault detection --Testing: Activity to provoke failures in a planned way --Debugging: Find and remove the cause (Faults) of an observed failure --Monitoring: Deliver information about state => Used during debugging -Fault tolerance --Exception handling --Modular redundancy.

After the scenarios are formulated

-Find all the use cases in the scenario that specify all instances of how to report a fire -Describe each of these use cases in more detail --Participating actors --Describe the entry condition --Describe the flow of events --Describe the exit condition --Describe exceptions --Describe nonfunctional requirements -Functional Modeling

Black Box Testing

-Focus: I/O behavior --If for any given input, we can predict the output, then the component passes the test --Requires test oracle: Expected test results -Usually, Input is valid across range of values --Developer selects test cases from 3 equivalence classes: ---Below the range ---Within the range ---Above the range

Functional vs. Nonfunctional Requirements

-Functional Requirements --Describe user tasks that the system needs to support --Phrased as actions ---"Advertise a new league" ---"Schedule tournament" ---"Notify an interest group" -Nonfunctional Requirements --Describe properties of the system or the domain --Phrased as constraints or negative assertions ---"All user inputs should be acknowledged within 1 second" ---"A system crash should not result in data loss".

System Testing

-Functional Testing: Validates functional requirements -Performance Testing: Validates non-functional requirements -Acceptance Testing: Validates clients expectations

Types of Requirements

-Functional requirements --Describe the interactions between the system and its environment independent from the implementation" ---An operator must be able to define a new game. " -Nonfunctional requirements --Aspects not directly related to functional behavior. ---"The response time must be less than 1 second" -Constraints --Imposed by the client or the environment ---"The implementation language must be Java " --Called "Pseudo requirements" in the textbook.

Acceptance Testing

-Goal: Demonstrate system is ready for operational use --Choice of tests is made by client --Many tests can be taken from integration testing --Acceptance test is performed by the client, not by the developer. -Alpha test: --Client uses the software at the developer's environment. --Software used in a controlled setting, with the developer always ready to fix bugs. -Beta test: --Conducted at client's environment (developer is not present) --Software gets a realistic workout in target environment

Coupling and Coherence of Subsystems

-Goal: Reduce system complexity while allowing change -Coherence measures dependency among classes --High coherence: The classes in the subsystem perform similar tasks and are related to each other via associations --Low coherence: Lots of miscellaneous and auxiliary classes, no associations -Coupling measures dependency among subsystems --High coupling: Changes to one subsystem will have high impact on the other subsystem --Low coupling:A change in one subsystem does not affect any other subsystem

Different Types of Requirements Elicitation

-Greenfield Engineering --Development starts from scratch, no prior system exists, requirements come from end users and clients --Triggered by user needs -Re-engineering --Re-design and/or re-implementation of an existing system using newer technology --Triggered by technology enabler -Interface Engineering --Provision of existing services in a new environment --Triggered by technology enabler or new market needs

Prioritizing requirements

-High priority --Addressed during analysis, design, and implementation --A high-priority feature must be demonstrated -Medium priority --Addressed during analysis and design --Usually demonstrated in the second iteration -Low priority --Addressed only during analysis --Illustrates how the system is going to be used in the future with not yet available technology

Inheritance

-Inheritance is another special case of an association denoting a "kind-of" hierarchy -Inheritance simplifies the analysis model by introducing a taxonomy -The children classes inherit the attributes and operations of the parent class.

Properties of Layered Systems

-Layered systems are hierarchical. This is a desirable design, because hierarchy reduces complexity --low coupling -Closed architectures are more portable -Open architectures are more efficient -Layered systems often have a chicken-and-egg problem

Repository Architectural Style

-Subsystems access and modify data from a single data structure called the repository -Historically called blackboard architecture (Erman, Hayes-Roth and Reddy 1980) -Subsystems are loosely coupled (interact only through the repository) -Control flow is dictated by the repository through triggers or by the subsystems through locks and synchronization primitives

Model-View-Controller Architectural Style

-Subsystems are classified into 3 different types --Model subsystem:Responsible for application domain knowledge --View subsystem: Responsible for displaying application domain objects to the user --Controller subsystem: Responsible for sequence of interactions with the user and notifying views of changes in the model

Guidelines for Formulation of Use Cases

-Name --Use a verb phrase to name the use case. --The name should indicate what the user is trying to accomplish. Examples: ---"Request Meeting", "Schedule Meeting", "Propose Alternate Date" -Length --A use case description should not exceed 1-2 pages. If longer, use include relationships. --A use case should describe a complete set of interactions. -Flow of events: --Use the active voice. Steps should start either with "The Actor" or "The System ...". --The causal relationship between the steps should be clear. --All flow of events should be described (not only the main flow of event). --The boundaries of the system should be clear. Components external to the system should be described as such. --Define important terms in the glossary. -Name of Use Case -Actors --Description of Actors involved in use case -Entry condition --"This use case starts when..." -Flow of Events --Free form, informal natural language -Exit condition --"This use cases terminates when..." -Exceptions --Describe what happens if things go wrong -Special Requirements --Nonfunctional Requirements, Constraints

Client/Server Architectures

-Often used in the design of database systems --Front-end: User application (client) --Back end: Database access and manipulation (server) -Functions performed by client: --Input from the user (Customized user interface) --Front-end processing of input data -Functions performed by the database server: --Centralized data management --Data integrity and database consistency --Database security

Client/Server Architectural Style

-One or many servers provide services to instances of subsystems, called clients -Each client calls on the server, which performs some service and returns the result --The clients know the interface of the server --The server does not need to know the interface of the client -The response in general is immediate -End users interact only with the client.

Requirements Elicitation

-Our first course of action is to understand what does the customer want? -How do we implement it so that it meets the customer's expectations? -How much liberty do we have when implementing components of the system? Does the customer care about "how" things are implemented or do they just care that it fulfills their need? -Requirements elicitation: Definition of the system in terms understood by the customer ("Requirements specification") -Analysis: Definition of the system in terms understood by the developer (Technical specification, "Analysis model") -Requirements Process: Contains the activities Requirements Elicitation and Analysis.

MVC: Model View Controller-Why?

-Problem:In systems with high coupling changes to the user interface (boundary objects) often force changes to the entity objects (data) --The user interface cannot be reimplemented without changing the representation of the entity objects --The entity objects cannot be reorganized without changing the user interface -Solution: Decoupling! The model-view-controller architectural style decouples data access (entity objects) and data presentation (boundary objects) --The Data Presentation subsystem is called the View --The Data Access subsystem is called the Model --The Controller subsystem mediates between View (data presentation) and Model (data access)

Types of Nonfunctional Requirements

-Quality requirements --Usability --Reliability ---Robustness ---Safety --Performance ---Response time ---Scalability ---Throughput ---Availability --Supportability ---Adaptability ---Maintainability -Constraints or Pseudo requirements --Implementation --Interface --Operation --Packaging --Legal ---Licensing (GPL, LGPL) ---Certification ---Regulation

State Chart Diagrams

-Represent behavior of a single object with interesting dynamic behavior. -The behavior is modeled as transitions between states. -There is a starting state and a final state. -The arrows represent the transitions which occur due to events in the object

Requirements Validation

-Requirements validation is a quality assurance step, usually performed after requirements elicitation or after analysis -Correctness: The requirements represent the client's view -Completeness: All possible scenarios, in which the system can be used, are described -Consistency: There are no requirements that contradict each other. -Clarity: -Requirements can only be interpreted in one way -Realism: Requirements can be implemented and delivered -Traceability: Each system behavior can be traced to a set of functional requirements -Problems with requirements validation: --Requirements change quickly during requirements elicitation --Inconsistencies are easily added with each change --Tool support is needed!

Scenarios

-Scenario (Italian: that which is pinned to the scenery) --A synthetic description of an event or series of actions and events. --A textual description of the usage of a system. The description is written from an end user's point of view. --A scenario can include text, video, pictures and story boards. It usually also contains details about the work place, social situations and resource constraints. -Scenario: "A narrative description of what people do and experience as they try to make use of computer systems and applications" [M. Carroll, Scenario-Based Design, Wiley, 1995] -A concrete, focused, informal description of a single feature of the system used by a single actor. -Uses: -- Requirements Elicitation: As-is scenario, visionary scenario --Client Acceptance Test: Evaluation scenario --System Deployment: Training scenario

Types of Performance Testing

-Stress Testing: Stress limits of system -Volume testing: Test what happens if large amounts of data are handled -Configuration testing: Test the various software and hardware configurations -Compatibility test: Test backward compatibility with existing systems -Timing testing: Evaluate response times and time to perform a function -Security testing: Try to violate security requirements -Environmental test: Test tolerances for heat, humidity, motion -Quality testing: Test reliability, maintainability & availability -Recovery testing: Test system's response to presence of errors or loss of data -Human factors testing: Test with end users.

Subsystem Interfaces vs API

-Subsystem interface: Set of fully typed UML operations --Specifies the interaction and information flow from and to subsystem boundaries, but not inside the subsystem --Refinement of service, should be well-defined and small --Subsystem interfaces are defined during object design -Application programmer's interface (API) --The API is the specification of the subsystem interface in a specific programming language --APIs are defined during implementation -The terms subsystem interface and API are often confused with each other --The term API should not be used during system design and object design, but only during implementation.

System Design

-System design is the process of defining architectures, subsystems, and interfaces to satisfy specific requirements. -Traditionally, transformation occurs from the output analysis into a system design model. -System Design is decomposed into: --Identify and prioritize design goals --Design the initial subsystem decomposition --Refine the subsystem decomposition to address the design goals

System Design Products

-System design results in the following products: --Design Goals: Describe the qualities of the system that developers should optimize. --Software Architecture: Describing the subsystem in terms of subsystem responsibilities, system dependencies, hardware, control flow, access control and data storage. --Boundary use cases: Describing the system configuration, startup, shutdown, and exception handling issues.

Top-down Testing Strategy

-Test the top layer or the controlling subsystem first -Then combine all the subsystems that are called by the tested subsystems and test the resulting collection of subsystems -Do this until all subsystems are incorporated into the test -Stubs are needed to do the testing. Pros and Cons of Top-down Integration Testing -Pro --Test cases can be defined in terms of the functionality of the system (functional requirements) --No drivers needed -Cons --Writing stubs is difficult: Stubs must allow all possible conditions to be tested. --Large number of stubs may be required, especially if the lowest level of the system contains many methods. --Some interfaces are not tested separately.

OSI Model Layers and Services

-The Application layer is the system you are building (unless you build a protocol stack) --The application layer is usually layered itself -The Presentation layer performs data transformation services, such as byte swapping and encryption -The Session layer is responsible for initializing a connection, including authentication -The Transport layer is responsible for reliably transmitting messages --Used by Unix programmers who transmit messages over TCP/IP sockets -The Network layer ensures transmission and routing --Services: Transmit and route data within the network -The Datalink layer models frames --Services: Transmit frames without error -The Physical layer represents the hardware interface to the network --Services: sendBit() and receiveBit()

MVC vs. 3-Tier Architectural Style

-The MVC architectural style is nonhierarchical(triangular): --View subsystem sends updates to the Controller subsystem --Controller subsystem updates the Model subsystem --View subsystem is updated directly from the Model subsystem -The 3-tier architectural style is hierarchical(linear): --The presentation layer never communicates directly with the data layer (opaque architecture) --All communication must pass through the middleware layer

Integration Testing

-The entire system is viewed as a collection of subsystems (sets of classes) determined during the system and object design -Goal: Test all interfaces between subsystems and the interaction of subsystems -The Integration testing strategy determines the order in which the subsystems are selected for testing and integration.

Sequence Diagrams: Flow of Data

-The source of an arrow indicates the activation which sent the message -Horizontal dashed arrows indicate data flow, for example return results from a message -Iteration is denoted by a * preceding the message name -Condition is denoted by boolean expression in [ ] before the message name

Bottom-up Testing Strategy

-The subsystems in the lowest layer of the call hierarchy are tested individually -Then the next subsystems are tested that call the previously tested subsystems -This is repeated until all subsystems are included -Drivers are needed. Pros and Cons of Bottom-Up Integration Testing -Con: --Tests the most important subsystem (user interface) last --Drivers needed -Pro --No stubs needed --Useful for integration testing of the following systems ---Object-oriented systems ---Real-time systems ---Systems with strict performance requirements.

Scenario-Based Design

-The use of scenarios in a software lifecycle activity -Scenario-based design is iterative -Each scenario should be considered as a work document to be augmented and rearranged ("iterated upon") when the requirements, the client acceptance criteria or the deployment situation changes. -Focuses on concrete descriptions and particular instances, not abstract generic ideas -It is work driven not technology driven -It is open-ended, it does not try to be complete -It is informal, not formal and rigorous -Is about envisioned outcomes, not about specified outcomes.

Example of a 3-Layer Architectural Style

-Three-Layer architectural style are often used for the development of Websites: --1. The Web Browser implements the user interface --2. The Web Server serves requests from the web browser --3. The Database manages and provides access to the persistent data. -Often called a 3-tier architecture since web server and database server are on different hardware

How do we properly test?

-To develop an effective test, one must have: --Detailed understanding of the system --Application and solution domain knowledge --Knowledge of the testing techniques --Skill to apply these techniques -Testing is done best by independent testers --We often develop a certain mental attitude that the program should in a certain way when in fact it does not --Programmers often stick to the data set that makes the program work --A program often does not work when tried by somebody else.

Sequence Diagrams

-UML sequence diagram represent behavior in terms of interactions -Useful to identify or find missing objects -Time consuming to build, but worth the investment -Complement the class diagrams (which represent structure). -Sequence diagrams represent the behavior of a system as messages("interactions") between different objects. -Used during analysis -To refine use case descriptions -To find additional objects ("participating objects") -Used during system design to refine subsystem interfaces -Instances are represented by rectangles. Actors by sticky figures -Lifelines are represented by dashed lines -Messages are represented by arrows -Activations are represented by narrow rectangles

Types of Testing

-Unit Testing --Individual component (class or subsystem) --Carried out by developers --Goal: Confirm that the component or subsystem is correctly coded and carries out the intended functionality -Integration Testing --Groups of subsystems (collection of subsystems) and eventually the entire system --Carried out by developers --Goal: Test the interfaces among the subsystems. -System Testing --The entire system --Carried out by developers --Goal: Determine if the system meets the requirements (functional and nonfunctional) -Acceptance Testing --Evaluates the system delivered by developers --Carried out by the client. May involve executing typical transactions on site on a trial basis --Goal: Demonstrate that the system meets the requirements and is ready to use. -Regression Testing --The entire system --Carried out by test engineers --Goal: Determine if the modifications to a particular component have introduced faults on other components. -Automation Testing --As created or developed --Carried out by automated testing framework. Automated tests developed by test engineer or developer --Goal: Automatically execute test cases by a framework rather than manually by a tester. Allows for repeated execution.

Some Quality Requirements Definitions

-Usability --The ease with which actors can use a system to perform a function --Usability is one of the most frequently misused terms (("The system is easy to use") --Usability must be measurable, otherwise it is marketing ---Example: Specification of the number of steps -the measure! -to perform a internet-based purchase with a web browser -Robustness: The ability of a system to maintain a function --even if the user enters a wrong input --even if there are changes in the environment --Example: The system can tolerate temperatures up to 90 C -Availability: The ratio of the expected uptime of a system to the aggregate of the expected up and down time --Example: The system is down not more than 5 minutes per week.

UML Diagrams

-Use case diagrams --Describe the functional behavior of the system as seen by the user -Class diagrams --Describe the static structure of the system: Objects, attributes, operations and associations -Sequence diagrams --Describe the dynamic behavior between objects of the system -State chart diagrams --Describe the dynamic behavior of an individual object -Activity diagrams --Describe the dynamic behavior of a system, in particular the workflow.

Use Case Diagram: Textual Description

-Use cases can be described textually, with a focus on the event flow between actor and system -The textual use case description consists of 6 parts: 1.Unique name 2.Participating actors 3.Entry conditions 4.Exit conditions 5.Flow of events 6.Special requirements. -Textual Use Case Description Example 1. Name: Purchase ticket 2. Participating actor: Passenger 3. Entry condition: --Passenger stands in front of ticket distributor --Passenger has sufficient money to purchase ticket 4. Exit condition: Passenger has ticket 5. Flow of events: --1. Passenger selects the number of zones to be traveled --2. Ticket Distributor displays the amount due --3. Passenger inserts money, at least the amount due --4. Ticket Distributor returns change --5. Ticket Distributor issues ticket 6. Special requirements: None.

Use Case Diagram

-Used during requirements elicitation and analysis to represent external behavior ("visible from the outside of the system") -An Actor represents a role, that is, a type of user of the system -A use case represents a class of functionality provided by the system -Use case model: The set of all use cases that completely describe the functionality of the system.

When modeling a system, I need to model that my system will use 1 representative and 3 customers. This is an example of ______. (choose one)

-link -association -multiplicity (WRONG ANSWER - Aggregation)

Steps in Integration Testing.

1. Based on the integration strategy, select a component to be tested. Unit test all the classes in the component. 2. Put selected component together; do any preliminary fix-up necessary to make the integration test operational (drivers, stubs) 3. Test functional requirements: Define test cases that exercise all uses cases with the selected component 4. Test subsystem decomposition: Define test cases that exercise all dependencies 5. Test non-functional requirements: Execute performance tests 6. Keep records of the test cases and testing activities. 7. Repeat steps 1 to 7 until the full system is tested. The primary goal of integration testing is to identify failures with the (current) component configuration.

Unit Testing Heuristics

1. Create unit tests when object design is completed --Black-box test: Test the functional model --White-box test: Test the dynamic model 2. Develop the test cases --Goal: Find effective number of test cases 3. Cross-check the test cases to eliminate duplicates --Don't waste your time! 4. Desk check your source code --Sometimes reduces testing time 5. Create a test harness --Test drivers and test stubs are needed for integration testing 6. Describe the test oracle --Often the result of the first successfully executed test 7. Execute the test cases --Re-execute test whenever a change is made ("regression testing") 8. Compare the results of the test with the test oracle --Automate this if possible.

In a use case diagram, I'm modeling a system that has many exceptions or seldom invoke cases. I would use the ____ keyword to convey this in my model (choose one).

<<extends>>

Functional Testing

Goal: Test functionality of system -Test cases are designed from the requirements analysis document (better: user manual) and centered around requirements and key functions (use cases) -The system is treated as black box -Unit test cases can be reused, but new test cases have to be developed as well.

Performance Testing

Goal: Try to violate non-functional requirements -Test how the system behaves when overloaded. --Can bottlenecks be identified? (First candidates for redesign in the next iteration) -Try unusual orders of execution --Call a receive() before send() -Check the system's response to large volumes of data --If the system is supposed to handle 1000 items, try it with 1001 items. -What is the amount of time spent in different use cases? --Are typical cases executed in a timely fashion?

Which one is NOT a purpose of System Design?

Provide a detailed and coded prototype

To model the behavior of a system between different objects and annotate the messages sent between those objects, I would use a _____ diagram

Sequence