CMPT After Midterm Flashcards
(99 cards)
1
Q
What is System Modelling?
A
System modeling is the process of developing abstract models of a
system, with each model presenting a different view or perspective
of that system.
System modeling has now come to mean representing a system
using some kind of graphical notation, which is now almost always
based on notations in the Unified Modeling Language (UML).
System modelling helps the analyst to understand the functionality
of the system and models are used to communicate with customers.
2
Q
Abstraction
A
Is the act of representing essential features without including the background details or explanations
used to reduce complexity and allow efficient design and implementation of complex design
3
Q
What is UML
A
UML is a way of visualizing a software program using a collection of diagrams
4
Q
UML DIagram Types
A
- Activity diagrams, which show the activities involved in a process or
in data processing . - Use case diagrams, which show the interactions between a system
and its environment. - Sequence diagrams, which show interactions between actors and the
system and between system components. - Class diagrams, which show the object classes in the system and the
associations between these classes. - State diagrams, which show how the system reacts to internal and
external events
5
Q
An external perspective
A
where you model the context or
environment of the system.
6
Q
interaction perspective
A
where you model the interactions
between a system and its environment, or between the components
of a system.
7
Q
A structural perspective
A
Where you model the organization of a
system or the structure of the data that is processed by the system.
8
Q
A behavioral perspective,
A
where you model the dynamic behavior of the system and how it responds to events.
9
Q
System boundaries
A
- System boundaries are established to define what is inside and what
is outside the system.
10
Q
Interaction Model
A
An overarching set of design patterns that are consistent throughout an application
11
Q
Use Case Modeling
A
The Use Case Model describes the proposed functionality of the new
system.
- A Use Case represents a discrete unit of interaction between a user
(human or machine) and the system. - A Use Case is a single unit of meaningful work; for example login to
system, register with system and create order are all Use Cases.
12
Q
Sequence Diagrams
A
Sequence diagrams are part of the UML and are used to model the
interactions between the actors and the objects within a system.
- A sequence diagram shows the sequence of interactions that take
place during a particular use case or use case instance.
13
Q
Context Model
A
How context data are structured and maintained also demonstrates the other systems in the environment
of the system being developed
14
Q
Interaction Models: Sommerville
A
Modeling user interaction is important as it helps to identify user
requirements.
- Modeling system-to-system interaction highlights the communication
problems that may arise. - Modeling component interaction helps us understand if a proposed
system structure is likely to deliver the required system performance
and dependability. - Use case diagrams and sequence diagrams may be used for
interaction modeling.
15
Q
Use case modeling
A
The Use Case Model describes the proposed functionality of the new
system.
- A Use Case represents a discrete unit of interaction between a user
(human or machine) and the system.
16
Q
Class Diagrams
A
Class diagrams are used when developing an object-oriented system
model to show the classes in a system and the associations between
these classes.
17
Q
Generalization
A
- Generalization is an everyday technique that we use to manage
complexity. - Rather than learn the detailed characteristics of every entity that we
experience, we place these entities in more general classes (animals,
cars, houses, etc.) and learn the characteristics of these classes.
18
Q
Object Class Aggregation Models
A
A class that is a collection of other classes
ex car - engine, windows, brake
19
Q
Behavioral Model
A
Behavioral models are models of the dynamic behavior of a system as
it is executing. They show what happens or what is supposed to
happen when a system responds to a stimulus from its environment.
two types:
* Data Some data arrives that has to be processed by the system.
* Events Some event happens that triggers system processing. Events may have associated data, although this is not always the case.
20
Q
Data-Driven Modelling
A
Many business systems are data-processing systems that are primarily
driven by data. They are controlled by the data input to the system,
with relatively little external event processing.
- Data-driven models show the sequence of actions involved in
processing input data and generating an associated output.
21
Q
Event Driven Modeling
A
Real-time systems are often event-driven, with minimal data processing.
22
Q
State Machine Model
A
Model the behaviour of the system in response to external and internal events
23
Q
Computer Hardware Architecture
A
The set if rules and methods that describe the functionality, organization, and implementations of computer systems
24
Q
Software Architecture
A
refers to the fundamental structures of
a software system, the discipline of creating such structures,
and the documentation of these structures.
As an example, the systems that controlled the space
shuttle launch vehicle had the requirement of being
very fast and very reliable.
25
Advantages of explicit architecture
Stakeholder communication
* Architecture may be used as a focus of discussion by system stakeholders.
System analysis
* Means that analysis of whether the system can meet its non-functional
requirements is possible.
Large-scale reuse
* The architecture may be reusable across a range of systems
* Product-line architectures may be developed.
26
Architectural Representation
Simple, informal block diagrams showing entities and relationships
are the most frequently used method for documenting software
architectures.
27
Use of Architectural Models
As a way of facilitating discussion about the system design
As a way of documenting an architecture that has been designed
28
Architectural Views
* Each architectural model only shows one view or perspective of the
system.
It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are
distributed across a network.
29
A logical view,
shows the key abstractions in the system as objects or object classes.
30
A process view,
* which shows how, at run-time, the system is composed of interacting processes.
31
A development view
which shows how the software is decomposed for development
32
A physical view
which shows the system hardware and how software components are distributed across the processors in the system
33
MVC
A software design pattern for implementing user interfaces on computers. Divides into 3 parts: Model, View, and Controller
The model represents the data, and does nothing else. The model does NOT depend on the controller or the view.
The view displays the model data, and sends user actions (e.g. button clicks) to the
controller.
The controller provides model data to the view, and interprets user actions such as button clicks.
34
Golden Rule of MVC
The model represents the data, and does nothing else; the model
does NOT depend on the controller or the view
35
When to apply MVC
You should consider utilizing an MVC framework if you’re building an application with enough
heavy-lifting on the client-side to struggle with JavaScript alone. Choose incorrectly and you’ll end
up re-inventing the functionality provided by an MVC framework
36
*System Analysis
The process of understanding the system requirements and its environment. It is one of the initial stages of the software development life cycle. Is the process of breaking the system down into its individual components and understanding how each component interacts with the other components.
37
*System Design
Is the process of creating a design for the system to meet the requirements. It is the process of designing the architecture, components, modules, interfaces, and data for a system to satisfy the specified requirements.
38
Structured Analysis
A methodology used in software engineering to understand and define system requirements through a systemic approach. It focus on breaking down a system into smaller manageable components.
39
Object Oriented Analysis
A methodology that models a system based on real-world entities and their interactions. It focuses on identifying objects software eng requirements and devolving software in terms of a systems object model which comprises of interacting objects
40
Design and Implementation/Construction
Software design and implementation is the stage in the software engineering process at which an executable software system is developed
41
What are Buy off-the-shelf systems or (COTS)
For example, if you want to implement a medical records system, you can buy a package that is already used in hospitals. It can be cheaper and faster to use this approach rather than developing a system in a conventional programming
language
42
3 important characteristics of a bad design that should be avoided
* Rigidity- It is hard to change because every change affects too many other parts of the system.
* Fragility- When you make a change, unexpected parts of the system break.
* Immobility- It is hard to reuse in another application because it cannot be disentangled from the current application
43
Approaches to Identification
* Use a grammatical approach based on a natural language
description of the system.
* Base the identification on tangible things in the application
domain.
* Use a behavioural approach and identify objects based on
what participates in what behaviour.
* Use a scenario-based analysis. The objects, attributes and
methods in each scenario are identified.
44
Non-Programming Implementation Issues
Reuse:
Most modern software is constructed by reusing existing components
or systems. When you are developing software, you should make as much use
as possible of existing code.
Configuration management:
During the development process, you have to keep track of the many different versions of each software component in a configuration management system.
Host-target development:
Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system).
45
Software reuse
In general, the term “software reuse” refers to a situation in which
some software is used in more than one project
Thus “software” could refer either to source code or to
other products of the software life cycle, such as requirements,
designs, test plans, test suites, or documentation.
46
Software reuse levels
The abstraction level
* At this level, you don’t reuse software directly but use knowledge of
successful abstractions in the design of your software.
The object level
* At this level, you directly reuse objects from a library rather than writing the code yourself.
The component level
* Components are collections of objects and object classes that you reuse in
application systems.
The system level
* At this level, you reuse entire application systems.
47
Software Reuse costs
The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs
he costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high
costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system
48
Configuration Management
the name given to the general process of managing a changing software system
49
Configuration Management Activities
* Version management, where support is provided to keep track of the
different versions of software components.
* System integration, where support is provided to help developers
define what versions of components are used to create each version
of a system.
Problem tracking, where support is provided to allow users to report
bugs and other problems, and to allow all developers to see who is
working on these problems and when they are fixed
50
Host-Target Development
Most software is developed on one computer (the host), but runs on a separate machine (the target)
51
Development Platform Tools
An integrated compiler and syntax-directed editing system
that allows you to create, edit and compile code.
* A language debugging system.
* Graphical editing tools, such as tools to edit UML models.
52
Integrated Development Environments (IDEs)
An IDE is a set of software tools that supports different aspects of
software development, within some common framework and
user interface.
53
Component/System Deployment Factors
If a component is designed for a specific hardware architecture, or
relies on some other software system, it must obviously be deployed
on a platform that provides the required hardware and software
support
54
Open Source
open-source
software, or similar software whose source code is publicly available, is
developed. These are software products available with its source code under
an open-source license to study, change, and improve its design.
55
Open Source Licensing
Legally, the developer of the code (either a company or an individual)
still owns the code. They can place restrictions on how it is used by
including legally binding conditions in an open source software license
56
Software Testing
Testing is to make sure that the things the program in question does
are done right. You have a set of functions, and you test each
function making sure that function performs properly.
57
Software Verification
Verification ensures that what you have designed "does the job" -
i.e., you have a set of things the code in question needs to perform,
and verification ticks those off on the list
58
Verification vs Validation
* Verification:
The software should conform to its specification.
* Validation:
The software should do what the user really requires (i.e., meets
requirements
59
Software Inspections
These involve people examining the source representation with the aim of
discovering anomalies and defects
60
Development Testing
Development testing includes all testing activities that are carried out by the team developing the system
61
Unit Testing
Unit testing is the process of testing individual components in isolation
62
Component testing
where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces
63
System testing
where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on
testing component interactions
64
Automated Testing
In automated unit testing, you make use of a test automation
framework (i.e., JUnit) to write and run your program tests
65
Testing Strategies
Partition testing, where you identify groups of inputs that have
common characteristics and should be processed in the same way.
Guideline-based testing, where you use testing guidelines to choose
test cases.
66
Partition Testing
Input data and output results often fall into different classes where all
members of a class are related
Each of these classes is an equivalence partition or domain where the
program behaves
Test cases should be chosen from each partition
67
Interface Testing
Objectives are to detect faults due to interface errors or invalid
assumptions about interfaces
68
Use-Case Testing
The use-cases developed to identify system interactions can be used
as a basis for system testing.
* Each use case usually involves several system components so testing
the use case forces these interactions to occur
69
Test-Driven Development
Test-driven development (TDD) is an approach to program
development in which you inter-leave testing and code development
Tests are written before code and ‘passing’ the tests is the critical
driver of development
70
Benefits of Test-Driven Development
Code coverage: Every code segment that you write has at least one associated test
Regression testing - testing the system to check that changes have
not ‘broken’ previously working code
Simplified debugging
System documentation
71
Release Testing
Release testing is the process of testing a particular release of a system that is intended for use outside of
the development team
72
Requirements-Based Testing
Requirements-based testing involves examining each requirement
and developing a test or tests for it
73
User Testing
User or customer testing is a stage in the testing process in which
users or customers provide input and advice on system testing
74
Sources of Software Unreliability
Failure in Design and Development
Failure during Operation
Failure in maintenance
75
Product Requirement
prescribe properties of a system or product
76
Process Requirements
prescribe activities to be performed by the developing organization, For instance, process requirements could specify the methodologies that must be followed and constraints that the organization must follow
77
Types of Requirements
User Requirements - Statements in natural language plus diagrams of the services the system provides and its operational constraints. This is written for customers
System requirements - A structured document setting out detailed descriptions of the system
services. This is written as a contract between client and contractor
Software Specification - * A detailed software description which can serve as a basis for a design or
implementation. This is written for the developers.
78
Software Requirements
description of the services that a software system must provide and the constraints under which it must operate
79
Use Case
list of actions or event steps, typically defining the interactions between a role and a system to achieve a goal (actor can be human or external system)
80
Problems In Req Phase
Initial defined reqs do not accurately account for the customers real problems
Reqs are not properly prioritized
Reqs stated at an inappropriate level of specification
-over specification - creates unnecessary constraints
under specification- create missing/incomplete definition of a req
81
Requirements Engineering Process (Non Agile)
Feasibility Study
Requirement Gathering
Software Requirement Specification (SRS)
Software Requirement Validation (SRV)
82
Feasibility Study
analysts does a detailed study about whether the desired system and its functionality are feasible to develop (costs, usability, maintainability, productivity)
83
Requirement Gathering
analysts/ engineer communicate with client to get their reqs on what the software should do/provide( can do things like interviews, prototyping, use cases, brainstorming)
84
Software Requirement Specification(SRS)
document that defines how software will interact with hardware/external interfaces, speed of operation, response time of system, portability of software across varous systems ..
Should include
-User Requirements are expressed in natural language
-Technical Requirements are expressed in structured language which is used inside the organization
-Design Desc should be written in Pseudo code
-Format of Forms and GUI screen prints
-Conditional and mathematical notations for DFDs
85
Software Requirement Validation
Validate reqs, or else later on their can be huge cost
Can be done by checking against following conditions
- If they can be practically implemented
-If they are valid and as per functionality
-if there are any ambiguities
-If they are complete
-If they can be demonstrated
86
Agile Methods and Requirements
Agile methods say producing requirements is a waste of time as requirements change quick rather use incremental requirements
87
Completeness and Consistency of Requirements
Completeness - Should include description of all facilities required
Consistency - There should be no conflicts or contradictions in the descriptions of the system facilities
88
Functional / Non Functional Requirements
Functional - statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations ( what the system should do)
Non Functional - are constraints on the services or functions offered by the system such as timing constraints, constraints on the development process(specifies how the system should perform/constraints on how the system will do so)
Single non functional req can generate number of functional reqs
89
Metrics for Specifying Non functional reqs
speed, size, ease of use, reliability, robustness, portability
90
Ethnography
Social Scientists Observe and analyze how people work
Derive requirements from how people actually work
91
92
Types of User Testing
Alpha Testing
Beta Testing
Acceptance Testing
93
Alpha Testing
Users of the software work with the development team to test the software
at the developer’s site
94
Beta Testing
A release of the software is made available to users to allow them to
experiment and to raise problems that they discover with the system
developers
95
Acceptance testing
Customers test a system to decide whether or not it is ready to be accepted
from the system developers and deployed in the customer environment.
Primarily for custom systems
96
Quality assurance
is the process of routine checks carried out to ensure that a
product or service is meeting its standard requirements
97
Shift left and Compress
‘Shift left’ means carrying out development and test
activities earlier in the project life cycle in order to detect defects sooner. ‘Compress’
relates to reducing the total number of defects introduced by a focused defect
prevention process
98
Residual product risk
In software testing, this is the product risk (risk of failure in
production) remaining in an application after test execution has completed. It is
expressed in terms of likelihood and impact and should be used as an input to help
decide if a product should be released to the next stage of development or the live
environment.
99
Cost of poor quality:
If all systems, processes and products were perfect, then
these expenses and costs would disappear. In other words they are costs that are
caused by defective testing materials.
