Unit 1 Flashcards

1
Q

What is a system?

A

An assembly of components that are connected together in an organised way.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is a socio-technical system?

A

A system seen as a whole, including the software, the hardware where it is installed and running, and the wider context that involves other technical components, but also people, organisations and other social structures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is meant by the viewpoint of a system?

A

A perspective on a system from the point of view of a particular person or group of people.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is meant by a system boundary?

A

A conceptual division between the system to be studied and ‘everything else’.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are the three important characteristics of software that affect its development and the likelihood of errors?

A
  1. Malleability - Software is easy to change. This malleability creates a constant pressure for software to be changed rather than replaced. Every change introduces the possibility of new errors. 2. Complexity - Software is often complex. Complexity can usually be recognised, but it is less easy to define. One item of software can be considered more complex than another if it requires more explanation. Part of that complexity arises from the potential variety of pathways between the components of a system. The number of errors is likely to depend on the complexity of a system. 3. Size. It is likely that there will be more errors in a large piece of software than in a small one.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

For each of these software characteristics: malleability, complexity, and size; explain why errors might arise in a piece of developed software.

A

Malleability - As change is easy to make, often changes are introduced without thorough consideration of the full consequences of each new change introduced. Complexity - The more complex a piece of software becomes, the more chances there are of a change affecting other parts of the software. Size - The greater the number of lines of code in a piece of software, the greater the number of likely errors.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is the defining quality of a good software system, and what are its main characteristics?

A

A good software system is one that meets its users’ needs. We can characterise a good software system as useful, usable, reliable, flexible and affordable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

How might greater flexibility make a software system moreaffordable over its whole life?

A

Users’ needs will change over time. The time taken to implement the changes in requirements in a flexible system is less than for lessflexible software. As labour costs are the most significant component of software costs, flexible software is more affordable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Give two reasons why a delivered software system might not meet its users’ needs.

A

Software systems are usually out of date even as they are being developed because:- some needs are often missed during requirements capture- users’ needs change with time.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What is meant by the maintainability of software?

A

The effort required to understand, locate and fix errors or make changes to a system i.e. how easily bugs can be found and fixed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is a legacy system?

What are the characteristics of a legacy system?

A

An old software system that is still required because it meets some useful purpose to an organisation. It is not considered to be replaceable and so it is maintained, usually on a restricted budget.

Organisations Love To Place Aged Computer Directors Above Modernisation

OLD

LARGE

developed using outdated TECHNIQUES

implemented using old PROGRAMMING languages

ALTERED a number of times since inception

CRITICAL to business

poor DOCUMENTATION

lack of AWAREWNESS in team (experience)

difficult to MAINTAIN

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What can we learn from legacy systems about developing a good software system?

A

A legacy system may have started out with all the characteristics of a good software system, yet those characteristics may have changed over time, resulting in a less flexible and maintainable product. As change is inevitable, the right processes should be in place to makechange happen in a more controlled way. This requires the adoption of standards and documentation conventions that help decision making on changes and how to introduce them. Any changes need tobe well documented so that software is still understandable and less dependent on the people initially involved with developing and maintaining the software.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Suggest a reason why legacy systems will always be a problem.

A

The inherent malleability of software makes it easy to change. A legacy system can therefore lack flexibility as a result of the number of changes made to it during its operational lifetime. The ability to bolt features and fixes onto a legacy system means that it will eventually become too fragile, and it will become precarious to go any further.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is meant by decomposition?

A

Splitting a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual. In software we identify a number of different activities or tasks that an individual or a group of individuals might perform.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What is meant by a module interface?

A

The interface of a module is a description of all the externally visible operations and what other modules need to know and do to make use of them,but without any details of how the operations are implemented internally.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is meant by abstraction?

A

It is the process of describing the essential features of a problem and ignoring other details. It permits you to concentrate on a problem at some level of generalisation, without regard to irrelevant detail. It also permits you to work with concepts, terms and models that are familiar in the problem environment (or domain).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Why might you consider splitting up a large project into smaller chunks (decomposition)?

A

There is a limit to how much one person can understand at any one time. So there is a limit to the size of a software system that any one person can deal with. By splitting a large project into smallerchunks, it is possible to identify a number of more manageable tasks for those involved.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

How does the complexity of a software system affect themaintenance task?

A

It is essential to be able to make a change to a software system without having to know all about that system. Each change becomes difficult when the flow of control and dependencies within programsare complex. The greater the number and nature of the dependencies, the harder it is to maintain a software system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

What is a module?

A

A module is any identifiable part of a software system that is considered separately. For example, modules may be subroutines, classes, library functions, or other constructs that may be treated independently.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Why does it help to have low coupling in a software system?

A

With low coupling, there are few dependencies between modules. Therefore changes made to one part (one or more modules) of a software system are less likely to propagate throughout the whole system. (A clear record of the dependencies between modules helps you to predict the impact of a proposed change to a software system.)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Give examples of the kinds of information that would be valuable when considering a change to a given module.

A

There are two kinds of information that contribute to the analysis of a proposed change:- Which modules are clients of the module in question? Thisinformation indicates how far a change may propagate through the software system.- What assumptions have been made in client modules of themodule in question? An understanding of the expectedservices of a module will help assess the risks associated with a particular change.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

What are the context dependencies of a module? How do they relate to a module’s interface?

A

The context dependencies for a module are the services of other modules that the module needs in order to work correctly. You can express the context dependencies for a module in terms of otherinterfaces. In effect, you can express the responsibilities of a module in terms of its interface and context dependencies. If the contextprovides the services that the module needs and clients meet any conditions specified in the interface, the module can guarantee the provision of the services described in its interface.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

What are the benefits of using modules with defined interfaces?

A

The benefits are as follows:- Developers will need to know only about the module’s interface (its syntax and what it requires and achieves – its semantics), not how it provides those services. Consequently developers can be more productive.- Developers can understand aspects of the software system more thoroughly, so fewer bugs will be introduced.- It should be easier to find bugs, as irrelevant modules are avoided.- The possibility of module reuse is increased once it is known what that module provides and requires.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Why does it help to have high cohesion in the modules of a software system?

A

With high cohesion, a module carries out a sensible set of operations or activities. Ideally high cohesion implies just one major abstraction per module. The interface abstracts away from what a developer must know in order to use a module. This makes it easier for developers to understand the purpose of the module and how to use it. In addition high cohesion tends to make a module more reusable in other applications, because it provides a set of operations that sit naturally together.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

What characteristics should a module display that will help to ensure that it is easy and cheap to develop and maintain, and that errors are kept to a minimum?

A

A module should have low coupling and high cohesion, represent a good abstraction, and have a well-defined interface that is an encapsulated abstraction of a well-understood concept.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Why is it important to achieve a balance between coupling and cohesion?

A

In constructing a system, you may have a choice between a smaller set of loosely coupled, less cohesive modules, or a larger set of tightly coupled, more cohesive modules. In the former case each module may be difficult to understand, while in the latter case the relationships between them may be over-complex. You need to strike an appropriate balance.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

What is meant by the software architecture of a system?

A

It is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

What are the characteristics of a component?

A

A component is a module that is considered to be a sufficiently good abstraction for the problem in hand. A component should be capable of being reused in future projects having the same software architecture, or being easily replaced at a later date within the existing software system. As with all modules, a good component has a well-defined interface and is an encapsulated abstraction of a well-understood concept, with strong cohesion and low coupling.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

How does the concept of an architecture contribute to component reuse?

A

The architecture of a software system embodies high-level decisions about the overall structure of the system, and this architecture may apply to more than one system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Which form of decomposition might be used in a software architecture?

A

The basic form of decomposition used in a software architecture is partitioning to meet a number of separate concerns, each concern being addressed by a subsystem. For example, you might want to separate the user interface layer from the core business services layer, or you may decide to build or reuse components and/or services for some of the partitions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

What are the similarities and differences between components and services?

A

There are similarities between a service and a component. They both promote reuse and flexibility. They both use public interfaces to allow requesters to make use of their functionality without relying ontheir implementation.There are differences too. A component is usually implemented in a specific object-oriented technology, therefore only clients compliant with that technology can easily communicate and integrate with it. In contrast, a service uses communication standards that allow the interoperation of diverse technologies.Finally, components tend to be associated with business entities, while services tend to be associated to business processes – they may realise part or the whole of the functions within such a process and may involve several business entities. Be aware that although this is a widely accepted classification, not everyone follows it, and you may see components called services and vice versa.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

What is meant by software quality?

A

At a general level, this defines the extent to which the customer is satisfied with the software product delivered at the end of the development process. At a more detailed level, it involves conformance to explicitly stated requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Give the characteristics of an engineering approach that support the argument that software development is an engineering discipline.

A

Software development follows an engineering approach provided that the following conditions are met:- it is concerned with meeting a set of requirements that are defined as clearly as possible- it uses a defined process with clear activities, each of which has at least one identifiable end product- developers can apply their skills and experience to the tasks demanded of them- validation and verification are regarded to be as essential as building the software itself- it makes sensible use of tools and standards- it follows a code of practice.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

What is a development process?

A

A set of rules that define how a software development project should be carried out. It incorporates a life cycle and involves a number of methods and procedures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

What is a deliverable?

A

An output, such as a design document or source code, of some software development activity whose production gives evidence of the completion of the activity.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

What is meant by a life cycle or process model?

A

The sequence in which a number of different activities are carried out to define an overall process for the development of a software system.

37
Q

There are many and varied methods used to develop software. However each one typically includes activities. What are these activities?

A

Domain modelling. Understanding the environment in which a system may be introduced – the business processes and rules. This is typically an activity that precedes a decision to develop a software system.Requirements (also known as requirements engineering). A set of steps including requirements elicitation, where you identify the problem, and requirements analysis, where you categorise, prioritise and model requirements. This defines what the system is to do.Design. Determining how you will solve the problem.Implementation. Acting upon the decisions made at the design stage.Testing. Testing what you have done so that you can determine whether or not you have solved the problem.

38
Q

What is meant by integration?

A

An activity in which individual software modules or components are combined into an executable whole.

39
Q

What is meant by quality management?

A

An activity that takes place throughout the software development process to ensure the quality of the final product.

40
Q

What is the waterfall model?

A

A particular life cycle that uses the analysis, design, implementation and testing activities in a simple sequence with little or no iteration. Some versions append the maintenance activity.

41
Q

In terms of process models, what is meant by iteration?

A

A distinct sequence of activities within a life cycle that may be repeated. Within a development process, the result is a (software) deliverable that conforms to certain criteria.

42
Q

What is meant by iterative and incremental development?

A

This development approach starts with a subset of the requirements and incrementally grows the system with further increments. Each increment is developed over several iterations; an iteration is a complete small project, with a short timeframe, consisting of analysis, design, implementation, testing and integration, and results in a partially working system.

43
Q

What should the role of project management be with respect to the deliverables of a development project?

A

A good software system must be affordable and available within an appropriate timeframe. Each deliverable uses resources, such as developers’ time, that add to its cost. Project management involves the identification of the appropriate deliverables for a given set of requirements and controlling the cost of producing them. Project management also involves ensuring that deliverables are produced on time and taking steps to cope with any delays.

44
Q

What is the difference between a customer and a user?

A

A customer is the person who pays for a software system, whereas a user is someone who will use that system on a day-to-day basis. A customer will also be a user when the proposed software system is intended to support their job.

45
Q

Suggest a reason why maintenance is a core activity in the development of a good software system.

A

Maintenance allows a software system to evolve over its operational lifetime so that it continues to be useful.

46
Q

What additional task is needed when the development of a software system is partitioned into a number of increments?

A

A task devoted to the integration of the increments to form the final software system will be needed.

47
Q

What are the assumptions on which the waterfall model is based?

A

There is an assumption that once a particular activity or phase is finished, it is not re-entered, and that the activities do not overlap but follow each other in a sequential life cycle. There is no need for reviewing or reworking. All this presupposes that an end point for each activity can be identified.

48
Q

What is meant by the term agile development?

A

An umbrella term used to describe a variety of methods that promote a set of practices that encourage simpler, more light-weight, faster and nimbler software development that can adapt to the inevitable changes in customer requirements. The continual realignment of development goals with the needs and expectations of the customer aims at software that better serves its purpose.

49
Q

Describe the extreme programming method.

A

It is one of the best-known agile methods. It is a light-weight method, based on intensive testing and incremental development. It defines a series of practices about how individuals and teams should work, how the environment should be set up, and how the work should be carried out. These practices include incremental design, test-first programming, programming in pairs, continuous integration, planning for the week, and so on.

50
Q

Describe the scrum programming method.

A

It is a popular agile approach, defines a set of roles, events, artefacts and rules. All events are timeboxed and have well-defined rules – scrum events comprise:the sprint – a development phase, no longer than a month, that has as a deliverable a useable working incrementthe sprint planning meeting – lasts no more than eight hoursthe daily scrum – a daily meeting, no longer than 15 minutes, looking at what has been done and planning the work for the next 24 hours.

51
Q

What is meant by risk management?

A

Analysis of risks in a development process and determination of steps to reduce them.

52
Q

Why might a software development company specialise in a certain kind of customer, such as those in banking or health care?

A

Through specialisation, a software development company can foster experience in a given domain, whether it is banking, health care or any other field of interest. The developers in that company would have (or would hope to gain) sufficient knowledge to understand the problems raised by the users and therefore be able to present solutions in a form that can be understood by those users. In addition, the company may develop and use a consistent development process that is appropriate to the set of customers in that domain.

53
Q

In which of the following activities would you expect to do your configuration management during a project? Analysis, Design, Implementation, Testing, Maintenance, Quality Management, or Project Management?

A

Maintenance deals with change. Configuration management is the discipline of managing and controlling change, and so you would expect maintenance to be where you would perform many of the configuration tasks. However there is a role for configuration management during the development process in, for example, ensuring the consistency of models. Quality management is the activity in which you would perform these tasks.

54
Q

Why are there additional risks when developing large projects?

A

The chances of failure increase as the size of a software project increases, as more errors are likely to be introduced. Effective communication between the members of a large team also becomes more difficult.

55
Q

What is added to a development process with the introduction of risk management?

A

The most important additional aspect is the use of the identification, evaluation and reviewing of risks that are carried out with each iteration of the development. These steps introduce feedback into the process to help ensure that the deliverables at each stage are leading in a timely manner towards the correct product, and risks are controlled.

56
Q

What is meant by traceability?

A

The ability to trace the history of each requirement from problem description through conceptual and specification models to the implementation and deployment models in order to reconstruct the significant events that led to the final operational software system. The ability to record information that will allow any investigation to reconstruct events, changes and reasons for change.

57
Q

Why is traceability important to the development of software?

A

Traceability is important for the reconstruction of significant events. In software development it should be possible to follow all the activities undertaken in response to a proposed change. In particular, you should be able to trace backwards from an implemented component or components, through their design, to a given requirement.

58
Q

How does documentation contribute to traceability within a development project?

A

Within a development project, documentation records the progress from requirements to implementation (and beyond). It is possible to identify each requirement and follow the actions taken to implement a solution to that requirement. You might, quite simply, be required to show that you have implemented each requirement correctly.

59
Q

Which activity or activities in the development process are most affected by poor documentation?

A

All seven activities will be affected by poor documentation. The maintenance and quality management activities will be most affected because they rely on the existence of traceability within the outputs of a development activity.

60
Q

For what kind of software system might you minimise or even avoid any documentation?

A

If a proposed software system is likely to have a short lifetime and will be discarded after use, it may be acceptable to minimise or avoid the task of documentation.

61
Q

How would you characterise agile documentation?

A

Agile documentation should be gathered with a purpose, should be easy to use and above all should justify the effort put into gathering it. There is no reason why this shouldn’t apply to any kind of documentation but often software development produces heavy documentation that is rarely used.

62
Q

Why is it important to review the contents of your project notebook?

A

The act of reviewing your notes helps you to identify what worked and what did not, as long as the notebook records accurately what you did and when. A review helps you to trace the events that led to the decisions you made since your previous review. Regularly reviewing your notes also enables you to check that you have followed up on all the decisions that you made.

63
Q

What are the main problems associated with the development of software? You should be able to identify at least six.

A
  • difficulty in capturing all the user requirements- difficulties in managing and developing large and complex systems- not meeting users’ requirements and avoiding dissatisfaction with the completed software- continual changes in user requirements (often referred to as requirements creep)- maintaining poorly documented software- the presence of errors introduced unknowingly during development- a changing world leading to changes in the needs of the users and decreasing the usefulness of the software- low productivity of those developing software, and difficulties in measuring that productivity- ensuring the quality of a software system.
64
Q

How do you think a large-scale project differs from a small-scale project in terms of the management of the development team?

A

As the size of a project increases, so does the number of people involved, and consequently the complexity of the interactions involved, and the difficulty of managing the team. As with programs, the greater the complexity of interaction, the greater the chance of errors occurring due to poor communication.

65
Q

What management steps might be taken to tackle the problems that arise in a large-scale project?

A

One of the functions of software project management is to manage project complexity. One way to achieve this aim is to modularise project teams by splitting them up into a number of groups. Each group performs a specific task and communicates with the other groups through one person (for example, the head of the group). Another way, encouraged by an agile approach to development, is to encourage practices of communication and cooperation in development, such as working in pairs and having daily short meetings.

66
Q

Process models sometimes show only the software-creation activities and exclude software maintenance. What problems are associated with the use of such models?

A

If maintenance is not mentioned, it is likely that it will not be considered to be an integral part of the overall software process model. This may result in a design that does not take the needs of maintenance into account, and hence a product that is difficult and expensive to change. This is especially likely if time and/or budget are already tight.

67
Q

What kinds of software system would be best suited to an iterative and incremental development process?

A

Software systems where the problem can grow incrementally or where it falls naturally into partitions, each of which represents a fairly self-contained unit that could be developed and delivered on its own to provide the users with a useful chunk of functionality, would be well suited to this model. An iterative and incremental approach allows several design issues to be tackled simultaneously and enables the system to be implemented in relatively small steps in order to contain the complexity. Of course, this assumes that the design can be partitioned.

68
Q

It has been said that ‘the maintenance activity begins with the first deliverable of a development project’. What does this imply about the maintenance activity?

A

This refers to the fact that there could be deliverables, such as requirements documents, that exist prior to any software being built, and these also require maintenance. For example, you might detect errors or inconsistencies in a document that lists the important terms in your users’ domain, or you might have to respond to changes in the environment, which may be due to new regulations or market forces.

69
Q

What is a model?

A

A model, in terms of software development, is an abstract representation of a specification, a design or a system, from a particular point of view. In general, it is a simplification of reality, created in order to understand an aspect or viewpoint of the system in question.

70
Q

What is a ‘good model’?

A

A ‘good model’ is an abstraction that allows those involved to concentrate on the essentials of a complex problem by excluding non-essential details while capturing those of interest.

71
Q

What are the two kinds of rule that govern the use of a modelling language?

A

A modelling language is normally diagrammatic, although it can be textual. In common with natural language, there are two distinct kinds of rule: - those that determine whether or not a diagram is legal – the syntax of a diagram - those that define what a legal diagram means – the semantics of a diagram.

72
Q

Does a modelling language need to be associated with a particular development process?

A

No, a modelling language does not dictate how it should be used and it is up to a development process to define which notations are appropriate and how they should be used. With experience practitioners tend to pick and mix from different modelling languages and use the notations that are most appropriate to the task – most modelling languages do not provide notations for all types of tasks.

73
Q

What are the required characteristics of a standard modelling language?

A

When choosing a modelling language, it should be: - sufficiently expressive - easy to learn and use - unambiguous - widely used - supported by suitable tools.

74
Q

How does a standard modelling language contribute to software development?

A

A standard modelling language helps when new people join a project – a common modelling language reduces the time needed to enable them to become productive team members. Also, when a modelling language is widely used, it is likely that project components will have been constructed using that language. This makes the software easier and cheaper to maintain.

75
Q

Should you try to capture everything about a design in a single model?

A

No, because you will be interested in different aspects of a design at different times, and different models of your design will be built to reflect your interpretations of users’ needs.

76
Q

What is the difference between a structural and a behaviour model?

A

A structural model describes the elements of the system and their relationships to other elements. A behaviour model describes the behaviour of a system over a period of time.

77
Q

Do the models used in a given development project need to be consistent?

A

Yes, the whole set of diagrams should contain the different aspects of a single software system, so they should not contradict one another. For example, there must be some consistency checking between the static and dynamic models. This can be automated by a suitable tool.

78
Q

What is the Unified Process (UP)?

A

A popular iterative and incremental process for building enterprise systems based on an object-oriented approach. It consists of four phases: inception, elaboration, construction and transition.

79
Q

What happens in each phase of a UP project?

A

Inception. The business case is developed, together with an idea of the scope of the system and a rough estimate of the effort required. Elaboration. The core of the system is developed in an iterative fashion. In this phase all major risks are addressed and resolved, most of the requirements are identified and dealt with, and a more realistic estimate of the effort required is made. Construction. The final product is constructed, including the remaining lower-risk and easier elements of the system, again in an iterative fashion. Transition. This includes beta testing and deploying the system.

80
Q

What is meant by timeboxing?

A

Allocating short fixed periods – for example, three to four weeks – to each iteration.

81
Q

List and briefly describe the five different views of a system’s architecture as defined by the UP.

A

The use case view contains the basic scenarios that describe the users and the tasks that they need to perform with the aid of a software system. These scenarios are partitioned into use cases. The logical view is concerned with the functional requirements of the software system. What should the software do for its intended users? Typically this involves the construction models that represent the main elements of a system and how they interact. The implementation view is concerned with the organisation of the code modules that comprise a software system. Typically it addresses the management of source code, data files and executables. The deployment view is concerned with the relationship between the various executables (and other run-time components) and their intended computer systems. The process view is concerned with aspects of concurrency. What are the processes and threads? How do they interact? It deals with such things as response time, deadlock and fault tolerance.

82
Q

What is the purpose of domain modelling?

A

Domain modelling is concerned with gaining an understanding of the environment in which any system that is designed must operate.

83
Q

What is the role of each of the artefacts produced during domain modelling?

A

During domain modelling, we produce the following artefacts: - initial problem statement – a description of the problem - behaviour model – a description of the business processes and behaviour of the domain - business rules – constraints on the way the behaviour model operates - glossary – definitions of relevant terms - structural domain model – an initial structural model representing the concepts relevant to the domain.

84
Q

What is the purpose of the requirements phase?

A

The requirements phase is concerned with establishing and modelling what a software system must do.

85
Q

What is the purpose of analysis?

A

Analysis starts modelling the structure and behaviour of a software solution from a user’s perspective.

86
Q

What is the purpose of design?

A

Design is concerned with making decisions concerning how a system will meet its specification.

87
Q

What is the role of each of the artefacts produced during design?

A

During design you produce the following artefacts: - structural model, an updated version of the one produced during analysis but with its operations specified - behavioural models, showing how objects in the system will interact and behave internally, and also how functionality will be distributed across the system.

88
Q

Suppose you and a colleague used UML on a particular development project. What would be the consequences of introducing symbols or notations that were not defined in UML?

A

Such an extension would incur costs as well as offering potential benefits. The costs include the need to communicate the syntax and semantics of your new symbols or notation to other developers. The benefits include the ability to express concepts specific to your project that could be more meaningful in your context.

89
Q

In the past, there have been many attempts to standardise modelling notations and languages. How might the choice of modelling language affect the maintenance of a software system?

A

Every time a new standard notation or language is defined, it allows new software systems to be built using that standard. It can only help with existing software retrospectively. For example, a developer might use the new standard to express a proposed change to the software. There is no guarantee that an existing software system used any modelling language at all, let alone any agreed standard for one. Even if a standard was used, new staff arriving on the team for the purpose of maintenance might not know about it. Each variety of standard would affect the organisation of a component library. For example, if components using a particular standard were to be put in a library, the descriptions would be likely to require some maintenance as that standard changes over time.