• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
CM10193 Software Engineering Revision Notes
 

CM10193 Software Engineering Revision Notes

on

  • 543 views

Revision Notes for the CM10193 Software Engineering course at the University of Bath

Revision Notes for the CM10193 Software Engineering course at the University of Bath

Statistics

Views

Total Views
543
Views on SlideShare
543
Embed Views
0

Actions

Likes
0
Downloads
43
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    CM10193 Software Engineering Revision Notes CM10193 Software Engineering Revision Notes Document Transcript

    • CM10193 Software Engineering Lecture 1 What is software engineering? Software engineering is the adaptation and practical application of knowledge of computer science concepts to deliver good software solutions for systems as well as subsystems. Why does software engineering matter? The software crisis of 1968 [machines were getting more powerful and software creation for small systems did not scale up] meant that a managed approach to software production was needed, and a practical application of computer science developed into software engineering concepts. What are the values and costs of software engineering? Value ­ All developed nation’s economies depend on software, and software engineering expenditure is a large part of amount the Gross National Product of all of these developed nations. Cost ­ However the software component of a system tends to dominate the total costs for the system, and it’s maintenance costs more than the initial development. What is software? Software consists of the program itself, it’s configuration data and it’s documentation. Software can be bespoke ­ made for a specific user and purpose ­ or generic ­ of the shelf software created for a large range of users in many situations. What is good software? Good software will deliver it’s required functionality, and has several desirable properties; Usable ­ Simple for the user to understand, and meets their demands Maintainable ­ Easily evolvable to meet changing requirements Dependable ­ reliable in all situations Efficient ­ not wasteful of system resources How is good software created? Software process models are used to define a set of activities and their associated results to produce a good software product. Although there are several different models for this, there are common activities in all of them: specification, design, implementation, validation and evolution. What are the key challenges facing software engineering? Heterogeneity ­ developing flexible software that can be handled by a diverse range of   existing systems, support structures and legacy software Delivery ­ Meeting deadlines for the completion of complex software systems without      compromising on it’s quality. 1
    • Trust ­ developing techniques displaying to the user that the software will be reliable in a large range of possible situations What is a system? A system is a combinations of components in a purposeful way, with inter­related elements working together to achieve a common goal. This includes software and hardware that meets people's intentions and psychological capacity. System components(sub­systems) are interdependent, and their properties and behaviour are entwined. What is a subsystem? A subsystem is a smaller component of an overall system, that may or may not operate separately from the whole system. What is an emergent system property? Emergent system properties are the prominent properties of a whole system, such as robustness, maintainability, usability, result of component relationship and the dynamic performance of the system. What are the different type of system categories? Technical computer­based ­ These systems include software and hardware, and are not self aware. Socio­Technical ­ These systems include technical systems, but also include operations and users of the system. These systems are governed by organisational policy, and are non­deterministic (i.e the outcome will be different each time, and will depend of the operator judgement) What is a systems purpose? A systems purpose can be defined by its objectives, which should define why it is being created for a particular environment, including functional and organisational objectives. What is software systems engineering? Software systems engineering is a branch of software engineering for specifying, designing, implementing, validating and maintaining socio­technical systems. It is concerned with the services provided and the way the system is used, as well as the constraints on it’s development. Lecture 2 What are the generic activities in a software process regardless of the model? There are three main parts in a software process; designing the specification ­ functionality and constraints of the software, design and implementation ­ planning of architecture and choice of technology and realisation, validation ­ checking the implementation meets the specification, and finally evolution ­ maintenance and upgrades to the software as time goes on. 2
    • What are the four stages of the software lifecycle? Specification, Design & Implementation, Validation & Evolution What is a model? A model is an abstraction of a real world problem, with a selective description and is from a particular perspective and for a particular purpose. What is a software process? A software process is an organisational tool for software development, which has a lifecycle depending on it’s environment, and ensures a software products meets the needs for which they were created. A software process should serve to protects engineers from change induced chaos. What is a software process model? Software process models are a simplified description of activities that need to be carried out to create a successful software system, for managing and organizing software engineering activities in a project. What are the three different software process models? The waterfall model, the evolutionary development model & the component­based (re­use) model. What is the waterfall model? The waterfall model requires each stage of the software engineering process to be completed and signed off before moving on to the next stage, meaning that section cannot then be revisited. This model is suitable for change­proof requirement projects ­ i.e stable business environments with low chance of change (expansion, contraction or diversification). The advantage of the waterfall model is that it is a very clear project management model, with milestones at the end of each activity, and allows a simple workflow and allocation of responsibility. The disadvantage to this model is the difficulty in allowing for changing requirements, as few businesses will have stable requirements where operations and context of these operations are not subject to change. What is the evolutionary model? The evolutionary model allows progressive expansion of the software system, starting with an initial version of the system, and with customer feedback, create more and more prototypes until it evolves into a final version of the system. Here, specification, development and validation are not clearly separated. Although this obviously allows feedback from the customer to make sure the system fulfils their needs, there are several problems with evolutionary development. The system often ends up being brittle, as it is hard to understand, there is a lack of process visibility, and unplanned enhancements leads to poor architecture and difficult maintenance. This model is generally used for small sized and short­lifetime systems. What is the component­based model? 3
    • The component­based model includes the reuse of existing components or off the shelf systems. This involves creating a requirements specification, analysing the components, modifying the requirements, design of the system with reuse, and development and integration. The advantage of this model is shorter development time due to already existing components that do not have to be created. The disadvantage is the difficulties that could arise in the integration of the component with the developed components. What is iteration and why do we need it? Iteration involves cycling through things again, and can be applied to any of the generic software models, but is hard to do effectively ­ so there are special SPM’s created that include iteration. There is always pressure to change system requirements in the course of a project ­ for example from customer feedback ­ so results of earlier activities must be reworked and implications for later work must be considered as it can produce unpredictable results unless properly managed. Lecture 3 What is programming? Programming is a type of problem solving, splitting large tasks into successively smaller tasks until they are simple enough to be performed by instructions of a programming language. This goes from problem analysis, to establishing requirements ­ part of the problem, and designing, implementing and evaluating ­ part of the solution. What is an architecture? Describes how a large problem splits into manageable parts. Architecture is the process of designing/constructing, whilst reducing complexity but still adhering to functional, performance and cost goals. Abstraction/separation of concerns by modular organization ­ a simple description of components and connections. What is software architecture? Creating of software structures by identifying subsystems (by creating closely mapped requirements and dividing them into logical groups), establishing sub­system control and decomposing sub­systems into modules. The benefits of architectural design are stakeholder communication and large­scale reuse. Sub­system model is based around a structural style (repository, client­server, layered etc.). How is software architecture evaluated? How well it supports functional and non­functional requirements after deployment. Early evaluation comes from known properties of reference architectures. What is an architectural design document? Graphical models of the design with descriptive text, with the models presenting different 4
    • perspectives on the architecture. What are the different types of architectural models? Static structural models ­ show the components (classes) of a system and their relationship, static control modes ­ describe flow of control between subsystems, and dynamic/behavioural models ­ model the interactions between components. What are the different types of static structural models? Repository ­ uses a central storage of data, Client­Server ­ services on server used by client, Layered ­ data travels through different layers of the architecture. What is the Repository Model? Uses a central project repository which all sub­system communicate separately with, which they can also use to communicate with each other. Generally for systems using large amounts of data. Advantages ­ centralised backup/security, efficient way to share large data, easy to integrate new subsystems. Disadvantages ­ common point of failure, hard to replicate the repository, subsystems must compromise on their needs to conform to the model, data schema hard to change later on due to large dependency from subsystems on initial data scheme (limits evolution or both repository and subsystems), common backup/security policy enforced on all sub­systems. What is the Client­Server Model? Connects client via server over a network. 3 types of subsystems ­ client subsystems (uses services ­ data and functions ­ provided by servers), network subsystems (permit use of services) and server subsystems (offer services to other subsystems). Uses request (client side) and reply (server side) protocol. Advantages ­ extensible architecture, no shared data model so subsystems can organise data in any way. Disadvantage ­ may need to update clients to reap benefits of new server functionality. What is the Layered Model? Several layers of software/hardware built on top of each other which data has to travel through, each layer does something different with the data. Advantages ­ as long as interfaces are respected layers can be changed, only adjacent layers are affected if interface does change, can enforce security policies to create protected core, supports incremental development. Disadvantages ­ outer layers may need to access facilities encapsulated by inner layers, large communication overhead (data travels further so bigger delays) with more layers so there is a performance loss. How are the Software Architecture and Non­functional requirements related? The s.a effects the NF requirements as it’s structure can affect system­level attributes such as performance ­ reduced with small no. of subsystems with minimal communication, security ­ consider layered model with security validation protecting inner layers, safety ­ keep safety critical operations in a singles sub­system reducing complexity of safety validation, availability ­ 5
    • build in redundant components, maintainability ­ use fine grain components easily substituted, avoiding shared data structures (repository) etc. What is granularity? How far the problem can be split down; a fine­grained system is a larger number of smaller subsystems, a coarse­grained system is a smaller number of larger subsystems. Lecture 4 What is the role of iteration in a process? Due to the continuing change in requirements we have to accommodate this evolution using iteration. This can be applied to any of the structural models (repository, client­server, layered) but also has two special models that support it; spiral development and incremental development. What is the Spiral Model? The process is presented as a spiral, with each loop representing a phase of the software process, risks evaluated and resolved during the process, and no fixed processes (specification, design etc.) ­ loops of the spiral chosen as required. There are four sectors of the spiral model; objective setting ­ objectives for the phase are identified, risk assessment and reduction ­ activities put in place to reduce the key risks, development and validation ­ development model for the system is chosen (any generic model), planning ­ project reviewed and next phase of spiral planned. What is incremental development? 6
    • Development of the system is broken down into increments, each delivering part of the functionality, with higher priority requirements being fulfilled first. Once delivered, requirements for that increment are frozen but later requirements for later increments can still be evolved. Process goes; specify requirements, plan increments, design architecture, develop increment, verify increment, integrate, verify system, develop increment, verify, integrate, verify system etc. Advantages ­ customers gain immediate value, high priority requirements delivered first, lower risk of overall failure, early increments used as prototypes which can inform requirements for later increments. What are Agile Methods of software development? Software development methods based in iterative/incremental design, where requirements and solutions evolve through collaboration. Focuses on the software rather than it’s design or documentation. Key principles ­ customer involvement, incremental delivery, people not process, embrace change, maintain simplicity. What is Extreme Programming (XP)? An example of an agile method (rapid software development), taking good practices (iterative development, customer involvement) to the extreme, with the customer as part of the development team and new versions being built up to several times a day. Requirements are built as ‘story cards’ developed from user scenarios. XP uses test­first development ­ creating tests to validate parts of the software, before it has even been written. This makes sure the software meets all of the necessary requirements, and reduces chance of new increments introducing errors into the software. Code is refactored and integrated continuously to prevent brittleness of the software, so static verification is used ­ constant informal reviewing. There are limitations ­ XP is constraining (small co­located team) and invasive (pair programming), and is not suitable to all projects ­ client must agree to be part of the development team (time investment needed). What is rapid application development (RAD)? Type of agile software development focusing on rapid prototyping rather than planning of software, making it easier for requirements to change and means creating the software quicker ­ planning is done alongside development of the software. Used for data intensive business applications mostly. Lecture 5 What are requirements? Functional and non­functional foundations of successful systems. Requirements are decided by not only the f/nf needs of the system, but by users, domains and UCD, gathering evidence, the SRS (software requirements specifications) and scope of the system, as well as use cases and scenarios. Requirements are used to get from the human problem space to the technical problem space. They define all aspects of a system, including it’s capabilities and operational characteristics, as well as the development process for creating the software. They are written 7
    • as a set of structured and interdependent statements including high­level and low­level features and details. How is a system defined? A system is described by it’s needs, which will evolve into it’s features, which then can evolve into the system’s specific requirements. What are functional requirements? Function requirements are statements of services/features/functions the system should provide, relating to inputs & outputs. What are non­functional requirements? General (non­functional) properties of the system and it’s behaviour, also including dealing with the constraints on development and when/how it will be delivered. E.g system usability, performance, responsiveness, safety, security, technologies used, delivery schedule, QA standards used, etc. Generally structured in the following order; product requirements ­ how the system will behave, organisational requirements ­ compliance with policies, then external requirements ­ wiser constraints & development process. Why do we need precise requirements? Imprecise requirements may be mis­interpreted by different developers, so wrong end­product may be done, and dependencies may be missed between requirements causing conflicts in operations. Imprecise requirements can also not be (or be hard to) verify ­ e.g. ‘must be fast’ how can this be measured?. Precise requirements are ordered, labelled (index/name), listed with source, prioritised, and measurable along with the actual statement. What are the 6 properties of a good set of requirements? A good set of requirements are prioritized, correct, modifiable, traceable, unambiguous and verifiable. Lecture 6 Where do requirements come from? It can be hard to get a good set of requirements data from customers, as people struggle to explain what they need from a system ­ how to express express, or even what they need ­ and different people want different things, causing disagreements, and stakeholders will only tell you about their part of the problem. The business environment may also change, and new stakeholders becoming involved can change the requirements of the system. There is therefore no single solution to the problem of defining the requirements of the system, but different viewpoints helps to organise requirements information and identify integration challenges with conflicts and tensions. 8
    • What are the different types of viewpoints in requirements gathering? Interactor viewpoints ­ primary and secondary users, who interact directly with the system, Indirect viewpoints ­ tertiary users, who don’t use the system but influence the requirements, and Domain viewpoints ­ like standards and rules creating domain characteristics that influence the requirements. What type of written sources are used in requirements gathering? This can include documents (like example forms or existing data for the system) given to you by the stakeholders, domain information (codes of conduct, legal documents, case studies of similar domains), or product information about similar systems (features/scenarios of similar vendors systems). What are the other types of sources for requirements information? Direct evidence from stakeholders, like interviews with primary/secondary/tertiary users or observations made in the workplace. What is an interview? An interview is a guided (with goals and questions) conversation between engineers and domain experts. The SE team will prepare questions to stakeholders about the current socio­technical system, as well as the software system to be developed. Interviews are good for getting an understanding of stakeholders viewpoints (what they do, how they interact), but are not good for understanding domain requirements as engineers may not fully understand domain terminology or it may not be described to them correctly/well, which can be disastrous if they are not familiar with it. We have to predetermine which stakeholders to interview (time, budget), devise a scheme for bringing the data together from interview ­ requirements, and we have to select the correct equipment to take to interview (notebook ­ static info, or records ­ dynamic info). What are the structures of interviews? Fully structured interviews ­ interviewers stick to a predetermined set of questions. Unstructured interviews ­ no questions prepared, conversation with domain expert. Semi­structured interviews ­ prompts and guides but no rigid agenda. What is involved in interview practice? Behave ethically throughout ­ introduce self and purpose of interview, warm up questions, main body of questions, and closure. Beforehand we prepare a written summary of the purpose of the interview and explain them to the interviewee, obtaining their consent to time/quotes/right of correction etc. Be open minded (speak and listen), prompting the interviewee with questions/proposals. These are all ethical interview practices. What do we do after gathering requirement information? We can collate the requirement statements into a secure managed data store, making sure we manage change in the environment/requirements. We track dependencies/relationships, so we know in advance the knock­on effects of changing these requirements, and for architectural 9
    • implications. Lecture 7 Note: architectural design reminder ­ the overall structure of a system, and is the critical link between design and requirements engineering, resulting in a model that describes a set of communicating components. What is modularity? Modularity is the degree to which a systems components can be split into ­ called subsystems. We decide what the main elements of the system are and how to split them up, and how they will connect. Finer­grain specifications (further split up) are better, we need to show how each component delivers it’s functionality to service the other components, and need to design the control logic for processing to be done by the software system. What is modular decomposition? Progressively splitting up work that the system performs on a whole. Top­down decomposition into self contained subsystems, or bottom­up composition of modules thinking about putting together small pieces of well defined work. What is the representational formality debate? Simple block diagrams of the modules without formal semantics are food for informal design conversions and reduces effort documenting work, but limits their utility as a specification. What are the two decomposition techniques? Function oriented pipelining (pipe and filter model) ­ modules accept input data, process it, and send it to the next module as output. Modules arranged in sequence, with a fluid series of operations of the data moving through the pipeline. Piping is between modules, filtering is done by modules. Advantages ­ role of each module simple, reuse of modules, evolve system by adding new modules into pipeline easily. Disadvantages ­ defined data communication rules, hard to deal with event driven activities. Object oriented decomposition ­ modules are set of communicating objects with responsibilities for work (processing of data) to be done for that specific sub­system. To identify these objects by analysing scenarios ­ nouns are object, verbs processes ­ entities in the application becoming objects, or participating agents as objects. Objects have defined public interface for communication between objects in a subsystem or the whole system, with a hidden internal state, and are built from classes to construct parts of the program. Advantages ­ strong link with entities in the problem domain, encapsulation, permits fine­grain reuse (through inheritance) and extensibility. Disadvantages ­ creating objects costs processing time and memory, and must be managed and disposed of later on. What are control styles? Control styles supplement static structural models by describing the flow of control between 10
    • subsystems. There are two generic control styles ­ centralised control and event­driven control. What is centralised control? Centralized control involves using a dedicated subsystem as a system controller, stopping/starting all other subsystems. Involves two control models; Call­return model  ­ passes control from system controller to sub­system and back once that sub­system has finished processing, delegating to one subsystem at a time. Top­down subroutine model, hard to accommodate exceptions to normal operation but easy to analyse control flows. Centralised manager/event­loop model ­ co­ordinates subsystems as well as stopping/starting them, used for big concurrent systems, but induces large overheads, and has low independence at process level. Controller loops continuously, polling state of sensor devices, managing the execution of the processes. Can be used in soft real­time systems (no critical time constraints). What is event­driven control? Each subsystem responds to external stimuli ­ or events. An event is a signal or message sent from a process to a system as a whole, intercepted by other processes in the system called event handlers. There are two types of event­based control; broadcast models and interrupt­driven models. What is a broadcast model? The event is broadcast to all subsystems and any event programmed to respond to that event will handle it ­ simple evolution but conflicts possible. What are interrupt­driven models? They are hard real­time systems, and events are detected by a special interrupt handler which then control other processes in the system. There is a limited number of interrupt channels. Lecture 8 What are stakeholders? Stakeholders are those affected by the system or who may have an influence on it’s requirements, and can be individuals or representatives of a larger group. These are catagorized into three types of system users; primary users ­ frequent hands­on users, secondary users ­ occasional users or people who use it through an intermediary, tertiary users ­ people who are not users but are affected by the software system (a wider socio­technical system). What is a system domain? A domain is made up of practices, knowledge and values, and describes the characteristics of the work to be done. It also describes the socio­technical context of the technical system. They are used to focus effort on the most important parts of the system, helping to prioritize development/testing, and define requirements for specific knowledge and computation. Domains also ensure engineering assumptions are realistic. However the requirements of a domain can be hard to understand by the engineer as they are expressed in the language of the application 11
    • domain. Domain specialists understand the domain well so they give implicit requirements, and do not make them explicit (saying directly what is needed rather than implying it) What is User­Centered Development? UCD makes users and their goals the driver behind development of the software, involving users to develop good usable products, manage expectations (make sure users views of product are realistic) and foster ownership (make the user feel they have been listened to and have more of a stake in the outcome). UCD has three principles; focus on users and their normal tasks, empirical measurement (evidence not speculation), and iterative design (design, user test, measure, redesign). Users can be factored into the development by co­opting them on to the design team (expensive but valuable), with design workshops and interviews, evaluation sessions or via mailing. How do we manage expectation? Through user involvement in development so they can see capabilities from an early stage. Should be focused on their own activities/services, avoiding vague statements about performance/functionality. Should communication user requirements so they are understandable by users who don’t have technical knowledge, using natural language, table and diagrams so they can be understood. Lecture 9 What are the two kinds of requirements document? First is before a contractor bids, with requirements written in different ways of meeting the client organizations needs, and the second is after the contract has been awarded, writing a system definition for the client in more detail, so the client understand and can validate what the software will do. Who are the users of a requirements document? The client organisation ­ business managers, end users, maintenance (clients system engineers) and the developer organisation ­ architects, developers, contractor managers, test engineers. What is the context of a system? Systems exist within a context ­ the environment a system fits into. Software systems are usually subsystems of businesses or other organisations. What is the scope of the system? The elements of the clients problem that are to be central to the s.e effort, and deciding how much of the system context is relevant to the development of the software. This sets boundaries on the proposed system, deciding the functions handled by the system, the goals the system must meet, and defining the major elements of the system and how subsystems interact with their environment. 12
    • What is in a Software Requirements Specification (SRS)? Introductory section ­ purpose, scope, goals, User requirements Definition ­ services system provides to users and nf req’s system should fulfil, System architecture ­ high­level sub­system description, System requirements specification, System models, System evolution, Appendices & index. What is is IEEE standard document? Basic structure for effective requirements document. The IEEE SRS includes; introduction, overall description, specific requirements (external interface reqs, f, nf ­ performance, constraints & attributes ­ and other), appendix & index. What are structured language specifications? They specifications in which the descriptions that make up each requirements is constrained ­ all statements written in a standard way and terminology is limited. They can be difficult to relate specific to general, and cause modularity and amalgamation. How should requirements be written? With a standard uniform format, with consistent language and text highlighting for key parts of the requirement. What are graphical models used for? Diagrammatic representations of components of requirements and their relationships, and can be used to consider dependencies, reason about changes of state and to describe sequences of actions. An architectural system context model is just a simple block diagram of the whole context of a system, showing all of it’s subsystems. A process based system context model shows all of the processes in the whole system (with system boundary marks showing functions in different subsystems) and their relationships. Lecture 10 What are application architectures? Application architectures are architectures in the form of subsystems and control mechanisms of applications within modules that are common, which help to identify reusable components, so they are used for the internal architecture of an application looking at modularisation. Three example application architectures are event processing (instantaneous response essential), data processing (focus on large volumes of data) & transaction processing (data­centred but more frequent changes). What are event processing applications? Use a form of concurrent architecture where behaviour matters, where the system detects events and processes to change it’s state, and data structures are updated and re­displayed. What are data processing applications? 13
    • Data records processed in batches from a file/database rather than interactively ­ simple architecture of input­process­output, but the data structures are often complex. What are Transaction Processing applications? A transaction is a request by a process to read/write part of a database. This is a single atomic unit ­ all operations in the transaction need to be completed before a change is made to the database that is permanent. Systems that include a shared database usually treated as transaction processing applications due to access of same data by separate subsystems. More than one process can read at a time but only one process can write at a time (and only when no readers are active). Use layered and repository structural styles. What is service­orientation in large systems? Service­oriented architectures define large­scale modularity around the provision of services from different developers, requiring an integration layer to publish service availability and mediate transactions. Basically instead of taking subsystems from other systems and reconfiguring them into subsystems, s­o architectures allow easy integration from other systems via an integration layer, using data and integration standards. Lecture 11 What is a scenario? Scenarios are informal narrative descriptions of how a system can be used in ordinary language, detailing relevant user activity with a system and highlighting objects/relations in an episode of interaction. They can describe ordinary or exceptional interactions. Can be idiosyncratic (one perspective), as it’s hard to decide on and manage the amount of detail. What is scenario­based design? Uses scenarios to build the design of a system; clarity of communication, requirement elicitation and analysis via use­cases, software design and build, documentation and training, and evaluation. What are use cases? Use cases are scenario­based descriptions developed during requirements analysis, that embody a set of requirements on the system. They basically represent the system from the viewpoint of the user (called the actor) from an external point of view. They are models which helps visualise to the users the planned build and features of the software, and who can access what. Actors are external entities, usually roles (customer, salesman etc.) and are the boundary to the technical system and beneficiaries of system services. And actor plus system object makes and interaction. They only present behaviour seen externally, not internal implementation, and can be used to model how a subsystem behaves with respect to an actor. Represents in the UML by a static diagram with descriptive scenarios relating to user goals. What are sequence diagrams? 14
    • Sequence diagrams are models of how objects implement use­cases, and represent relationship between internal and external interactions, showing the order of event processing & dependencies. Lecture 12 What is object­oriented development? OO development comprises of; OO analysis ­ identify OO model of application domain to reflect entities and operations, OO design ­ identify OO model of software system to implement requirements, OO programming ­ realise the OO design. Typical activities in OO design process; define context & use cases, system architecture, main objects of the system, construct design models, specify object interfaces. There are two basic types of OO design model; static models (describing object classes), or dynamic models (describing interaction of objects). Good OO design = high cohesion /low coupling (functions in a class are similar and closely related, and modules don’t depend on each other). What is the Unified Modelling Language (UML)? UML is a set of graphical notation used to create OO software, representing both data and processes. Provides 13 (static+dynamic) modelling systems. We consider 4; class (static), use cases (dynamic) sequence (dynamic) and state machine (dynamic). What are the differences between objects and classes? An object is a self­contained entity with attributes and operations. A class is a generic definition of an entity for a set of similar objects. A class model provides a diagram of the static relations between classes (components of the system) and their associations within the application. What is inheritance in Object orientation? Child classes in the object hierarchy inherit attributes and operations from it’s parent(s) with extra specialisation. Good class model designs don’t inherit unnecessary attributes and name clashes are resolved meaningfully. What is an Entity­Relationship­Attribute (ERA) diagram? Type of semantic data model (a conceptual data model with semantics (meaning) included for interpretation which describe logical structure of input/output by the system), which shows the structure of data to be processed using entities, relationships and attributes. Must be accompanied by data dictionary for name management and storing organisational information. Lecture 13 More about UML UML is a visual modelling language for representing and reasoning about software with a very broad scope, with type families of tools; one to represent structure (static models) and one to 15
    • represent behaviour (dynamic models). What are behavioural models? Specify how system components interact with each other ­ data flow diagrams, state machine models, sequence diagrams. The second 2 are UML models, but data flow diagrams are a traditional approach to describe systems with a single thread of data, with data being transformed to an alternative representation without much interaction between components. What are sequence diagrams? Used to model interactions between objects, specifying how particular computations are performed by the system showing which objects talk to others and in what order. What are state­machine models (SMMs)? Used to design and analyse event processing systems (e.g. real­time systems).  At any time, all software systems are in one of a number of possible states ­ ‘ready for input’, ‘processing data’ & ‘displaying output’, and the state expose the time­relevant logic of software systems. State­machine models in the UML show how a system responds to stimuli (from external source or internal code). These include a graphical diagram and a descriptive table. Superstates are expanded additional SMMs. Lecture 14 Validation and verification (V&V) V&V is used throughout the lifecycle process at each stage to ensure the integrity of the system and the delivery of an effective system. There are two main categories of failure; constructing a system with performance/execution/logical defects, and delivering a system with no value. Verification tests to see if the software conforms to its specification, and Validation tests to see if the system can deliver valuable services to the user. What is a defect? A defect is a fault in a component of a system, but safety cases can be written to design system responses to the presence of defects. In a socio­technical system, a user could be the faulty component. Defect tolerance ­ level of confidence depends on how critical the system is to an organisation, and the degree of criticality comes from the nature of risk of system failure. What is a failure? A failure is usually a systemic problem that occurs when the system can no longer safely deliver a useful level of service. They usually occur when defects add together due to a series of unfortunate coincidences. We need to validate at system level to catch accumulation of defects. Validation Aims at ensuring the system works as its users intended, with evaluation throughout the design, with the design proceeding through iterative cycles of design­test­redesign. Evaluation establishes confidence that the software is fit for purpose, and the environment and type of use 16
    • will determine the degree of confidence that is needed. Lecture 15 Refining use cases We can simplify a use case by simplifying its scenario by factoring out common sub­tasks. Use case services can be composed of other services, and use cases can refer to one another if and their common sub­tasks. Services should be defined in terms of user tasks, and in a use case model can be mapped directly onto a particular subsystem or may be modelled by including intermediary services. Use cases may not relate directly to the architecture of the system, but the class model should be developed alongside use case models. What are sequence diagrams? Sequence diagrams model the behaviour of objects in certain situations, and adds system­level detail to use cases, showing sequence of event processing in the system. Also shows inter­object dependencies, and reads system activities across time. What are the challenges in modelling? Adequacy of conceptualization of current work, shelf life of task description. What are the challenges for representing/supporting user activity? Escape sequences ­ cancelling an operation halfway through, representation of parallel tasks ­ multi­tasking requires interruption and resumption, can impose unnecessary sequential constraints ­ order of required information vs. order users provide it in. What is the task­artifact cycle? Artifacts created from study of clients & their tasks, but people use these artifacts to do new tasks, causing a cycle. Cycle can’t be broken unless the new ways of working can be forecasted. Lecture 16 Ethics & Professional conduct Software engineers must work within the legal and social frameworks of society, and so professional s.e’s must act in compliance with relevant legislation and with an ethical and moral responsibility. Codes of conduct are set by professional bodies, and are necessary to maintain professionalism. Codes of conduct are a set of principles that are meant to guide rather than prescribe ­ ambiguous in application, used to aid professional judgement in ethical dilemmas. Difficulties ­ COC may be ambiguous, different parts may conflict, situation may not be covered, may put job at risk. They are always subject to continual development. ACM/IEEE code of ethics Has eight main principles; public, client/employer, product, judgement, management, profession, 17
    • colleagues, self. What is the Computer misuse act (1990/2006) ? Supports prosecution of computer­related crime. Guilty of a crime is ­ causes a computer to perform an action with the intent to secure access to information on any computer with known unauthorised access. Modification is a more serious offence again. What is a Denial of Service attack? DDoS attack is a new type of cybercrime, bombing a server with many requests to overload and crash it. Lecture 17 Science & Engineering Science ­ acquisition of objective knowledge through empirical methods to gather data. Engineering ­ application of scientific principles for practical purposes. Project management The key roles of a project manager are ­ proposal writing, project planning (schedule, costs), personnel allocation, project monitoring (checking and reviewing), delivery to client (reports/presentations). Scheduling the project is done by estimating the time and resources required to complete activities and order them into a coherent sequence. Time given depends on granularity (1­8 weeks), allowing contingencies (delays) and scheduling also considers concurrency and dependency. Scheduling methods Gantt chart ­ shows task timing, concurrency is clear, but dependencies/personnel responsibilities hard to see. Critical path chart ­ identifies critical tasks and the paths taken, allowing project managers to invest more resources to avoid project slip. Lecture 18 Cohesion Group cohesion means pulling together, caring about the team and willingness to share. Advantages ­ inhibitions to contribute are reduced, quality standard can be developed for the group, group member work closely so they can learn from each other and know their work. Influenced by organisational culture and personalities in the group. Can be encourage by social events, team­building, developing group identity and openness of information. Cohesive groups have loyal membership ­ good but can lead to restrictive practices. Groupthink is preservation of group irrespective of technical/organisational considerations ­ should be avoided. Communication strengthens cohesion. 18
    • Lecture 19 Risk management Risk ­ unwanted event that may occur with negative consequences Risk exposure (PRA ­probabilistic risk assessment) ­ Probability * negative effect Risk management ­ measuring/assessment of risk and development of strategies to manage it. What are the three types of risk? cost increase, quality degradation, organisational (business) risk. What is the risk management process? Risk identification ­ identify project, product and business risks via brainstorming/analogy, Risk analysis/prioritisation ­ assess probability/loss of risk, Risk control ­ planning (plan to minimise risk via avoidance/minimisation/contingency strategies) & resolution (implement plan), Risk monitoring ­ iterative process with project planning Critical Systems Development Types of critical systems; Safety critical, Mission critical, Business critical All concerned with safe operation ­ i.e dependability (availability, reliability & security). Cost rises exponentially with dependability. Specification for these systems should be risk driven, identifying risks and their causes, with safety requirements to reduce risks. Risk categorization Intolerable: must never arise, As low as reasonably possible (ALARP): minimise possibility of risk given cost and schedule constraints, Acceptable: consequences are acceptable and no extra costs should be incurred to reduce possibility. How can we identify the root causes of a risk? Fault tree analysis(FTA) ­ top­down technique, placing risk at the top of the tree and identify the system states that could lead to the hazard (linked by and/ors) Critical Systems Design Involves redundancy & diversity; for example of replicated subsystems or replicated internal verification routines. Fault tolerance Run­time fault checking for critical systems, with 4 aspects; fault detection, damage assessment, fault recovery & fault repair. Diversity can be achieved by: including requirements that differ approach to design, requiring implementations in different languages, requiring use of different development tools/environments, requiring different algorithms in some parts of the implementation. 19
    • Lecture 20 Ethical practice Doing the right thing, adhering to a code of honour, being decent and meeting moral obligations. Laws try to encode morality. What is the Regulation of Investigatory Powers Act (RIPA 2000) Ensures convert investigations do not infringe on human rights law, needing an interception warrant only awarded for policing/securing/safeguarding the economic well­being of the UK. Includes intrusive (in private) / directed (in public) surveillance and gathering of covert human intelligence ­ about someone gathered through a covert relationship. Data protection Act (1998) Respecting privacy by making aware of how information about them is obtained and used. Has four main concepts ­ Personal data; any data traced to a living identifiable person, Data subject: living person who is the subject of data, Data controller: person/organisation that processes data, & the processing of the personal data; any operation performed on data. The personal data is usually sensitive data that allows them to be identified. In software engineering sensitive personal data can be processed if; explicit consent given, other laws require it, when it is necessary, processing by non­profit trade union business, because secretary of state says so. Eight principles of data processing Fair, Adequate, Rights, Specific, Transfer, Accurary, Retention, Security Lecture 21 Quality The match between a product and it’s specification ­ but a specification may not match a client's expectations or there may be conflicts between customer and developer ideas about quality. So quality is always a compromise. There is a direct link between process and product quality in s.e, with individual skills & experience and external factors impacting the quality. What are the activities in Quality Management? Quality Assurance (QA); establishes standards for all projects run by an organisation, Quality planning: select standards for a particular project, Quality control; monitor quality standards for a particular project to make sure the S.E team are compliant. These are all independent from project management to avoid conflicts of interest. Quality assurance (QA) Defines how the entire SE organisation can achieve high quality and can assess adherence to its own standards. Process standards ­ define processes to be followed to ensure delivery of 20
    • product standards. Product standards ­ coding standards and presentation standards (product and document structure). Use of software standards; Advantages ­ encode best practice, adherence to a formal standard enforces adherence to this best practice, continuity between developers. Disadvantages ­ bureaucratic, perceived as pedantic and tedious, may not reflect recent innovations in best practice. To avoid these problems we can involve practioners in standards development, review standards & usage regularly, and standards should have associated tool support. Quality planning Writing a quality plan ­ identify standards that apply & new standards to be used. Plan should describe the desired product qualities and the processes by which they are assessed. Structure; intro, product plans, process descriptions, quality goals (e.ge robustness, security, reliability etc.), risk and risk management. Should be short and clear. Quality Control Checking the software development process to ensure that procedures and standards are being followed. Two approaches; quality reviews ­ discovery of system defects and inconsistencies and deviation from standards, short process, or automated software assessment & measurement ­ software measurement (given a metric value) allowing for comparisons. Lecture 22 Process measurement ­ Goal­Question­Metric paradigm Goals ­ what is it trying to achieve, Questions ­ areas of uncertainty, Metrics ­ relevent metrics to help answer questions. Process measures using quantifiable measurements ­ time, resources, occurrence. process improvement ­ measure, analyse, change Capability maturity model (CMM) Assesses sophistication of an ICT company's process improvement strategies. Levels; initial, repeatable, defined, managed and optimising. Lecture 23 variable ­ anything that can take different values factor ­ variable that influences observations variables are not always factors For comparisons to be fair, test conditions must be the same for each observation. 21