Very useful tools in requirements capture and description. Intuitive and easy to understand, so can discuss with client. Document behaviour of system from external point of view.
Can also be primary element in project planning and development and for systems validation. Widely adopted by OO community, called Stories in Agile World.
It describes a single functional requirement from a user’s point of view and describes the expected interactions between the user and the software.
A set of scenarios tied together by common user goal or a coherent unit of functionality
Sequence of steps describing an interaction between a user and a system. Can consider a scenario as an instance of a use case.
A use case does not and should not describe the inner workings of the software, it should not be considered as a software design artefact.
- Object interactions in successful borrowing
- Object interactions when the maximum number of copies on loan by member already reached
- Object interaction when member has a fine outstanding and pays fine
- Object interactions when borrower is not a valid library member
Graphical notation is made of an actor and use cases. They are accompanied by brief description of primary scenario in natural language and possibly some alternative scenarios. It can also add preconditions and postconditions which must be true before use case can start and after it completes. No UML standard on this.
There is no standard way to write the content of a use case and different formats work well in different cases.
The goal the use case is trying to satisfy main success scenario
A numbered list of steps where a step is a simple statement of interaction between the actor and a system
Extensions
Separately numbered lists, one per extension where an extension is a condition that results in different interactions from the main success scenario. An extension from main step 3 is numbered 3a etc…
Actor is a role that users play with respect to the system. Many users can play the same role, one user can play many roles. Actors are useful for identifying use cases, first establish actors, then their associated use cases. An actor does not have to be human, it can be an external system. Actors can be initiators or the receivers of value from a case also called primary actors.
Actors and use cases are also used for configuring systems for different types of users and negotiating priorities among uses – who wants what? Not all use cases come from actors. Responses to external events may help identify use cases and events may cause system reactions and user reactions.
Known as uses in earlier UML standards. Chuck of behaviour that is same across different use cases. Use include for avoiding repletion of requirements description.
Like another case but does a bit more. Captures alternative scenario and sort of extends the use case. Alternative functionality put in specialised use case that refers to the base use case. Can override base use case. Use generalisation for casual description of variation on normal behaviour.
Like generalisation except with more rules. Base Case must declare extension points. Extending use cases may extend one or more extension points indicated by text on line joining use cases. The extension conditions of each use case provide a framework for investigating all the title, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the stakeholders can spot issues that are likely to take a long time to get answers for. These issues should be planned for so that the answers can be ready when the development team gets around to working on them. Use extend for more controlled description of variation on normal behaviour.
Extend and generalisation allow splitting of a use case Elaboration phase used when the use case is getting too complicated Construction phase is used when we a case can’t be built in 1 iteration
With focus on user system interaction, analysts can miss situation where change to the business process would be more useful.
There are 2 categories of use cases:
-
System use case
- interaction with software
-
Business use case
- how business responds to event or customer or how to meet a user’s goal
We are recommended looking at business use cases first and finding system use cases for them later.
High cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain. Low coupling allows each unit to be effectively tested in isolation. A measure of how well a component or module fits together. A component should implement a single logical entity or function. Cohesion is a desirable design component attribute as when a change must be made, it is localised in a single cohesive component. Various levels of cohesion have been identified.
Coincidental cohesion (weak). Parts of a component are simply bundled together.
Logical association (weak). Components which perform similar functions are grouped. Similar functions.
Temporal cohesion (weak). Components which are activated at the same time are grouped.
Communication cohesion (medium). All elements of a component operate on the same data.
Sequential cohesion (medium). The output for one part of a component is the input to another part
Functional cohesion (strong). Optimal type of cohesion. Performs a single well defined action on a single object. Each part of a component is necessary for the execution of a single function.
- Not well defined, often difficult to classify cohesion
- Inheriting attributes from super classes weakens cohesion
- To understand a component, the super classes as well as the component class must be examined
- A measure of the strength of the interconnections between system components
- Loose coupling means components changes are unlikely to affect other components
- Shared variables or control information exchange lead to tight coupling
- Loose coupling can be achieved by state decentralisation and component communication via parameters or message passing.
- Altering another modules code (LISP, Assembler)
- Modifying data within another module
- fault that appears in one module may be due to another
- complicated understanding and debugging
- can be done via global variables or pointers or call by reference in C++ Java
-
Shared or global data
-
Procedure call with a parameter that is a switch (or a function pointer in C)
- I/O (command, device, buffer, length)
-
Procedure call with parameters that are pure data
- ideal is call by value, where a small number of parameters are used, and a copy of the data is passed to the procedure invoked
- clear what information is being communicated
-
Passing a serial data stream
- most ideal situation
- one module passes stream of data to another. Once passed, data is outside control of process/module. Like piping in UNIX. Data can be thought of as a temporary intermediate file. Only possible in languages that support concurrency such as Ada and Erlang and parallel C.
Object oriented systems are loosely coupled because there is no shared state and objects communicate using message passing. However, an object class is coupled to its superclasses. Changes made to the attributes or operations in a superclass propagate to all subclasses. Such changes must be carefully controlled.
Capturing use cases is a primary task during elaboration. It must have requirements captured before you can plan for them. You must collect all use case first and then model or explore some use cases and do conceptual modelling together which helps uncover other use cases. Each step of a well written use case should present actor goals or intentions and normally it should not contain any user interface details such as naming of labels and buttons. It is bad practice and will unnecessarily complicate the use case writing and limit its implementation.
- they are easy to understand and facilitate communication
- the list of goals provides the shortest summary of what the system will offer
- the main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do and what it will not do
- it provides the context for each specific line item requirement and a context that is very hard to get anywhere else
- it also provides a project planning skeleton to be used to build initial priorities, estimates, team allocations and timings. The use case extension scenario fragments provide answers to the many detailed, often tricky and ignored business questions: “What are we supposed to do in this case?”
- well written use cases also serve as a groundwork/guideline for the design of test cases and user manuals of the system. There are obvious connections between the flow paths of a use case and its test cases
- deriving functional test cases from a use case through its scenarios
- may miss requirements if too much emphasis is put on finding actors and their use cases. This problem can be relieved by use case analysis and conceptual modelling. Use cases are not well suited to capturing non-interaction-based requirements of a system such as algorithms or mathematical requirements or real time embedded requirements. They are also not well suited to capturing non-functional requirements. These are better specified declaratively elsewhere. They have no standard definition. Use case developers often find it difficult to determine the level of user interface dependency to incorporate in a use case. Keeping UI outside of use cases can make it difficult to visualise the product. Moreover, there is a danger of building a system which is not object oriented. This leads to a system abused by decomposition that is functionality driven and is unmaintainable and inflexible. Focusing on GUI instead can give a false idea of progress and makes negotiating difficult.
In Agile development, especially Extreme Programming, simpler user stories are preferred over use cases.
- Fails to do what users want it to do
- It is expensive
- It is not always fast enough
- It cannot be transferred to another machine easily
- Maintenance is expensive
- It is unreliable
- It is often late
- Meeting user’s needs
- Reducing software costs
- Improving reliability
- Delivery on time
Many argued that software development was in a crisis. Needed a scientific approach, based on sound principles and methods hence the term Software Engineering. Problems conflict with each other which is difficult to solve software issues
A few ideas have been suggested and tried to deal with above problems, greater emphasis on carrying out stages of development systematically. Computer assistance for software development, fourth generation languages.
-
Concentration on finding out exactly what the users of the system really want
-
Formal specification of requirements
-
Prototyping, demonstrating an early version of the system to the users
-
Using new programming languages
-
Testing – greater emphasis on trying to ensure that the software is free of bugs
Most important idea in improving software development is the software development lifecycle, in particular the waterfall model.
Development is split up into independent steps that are carried out in sequence
Requirements definition -> System and Software design-> Implementation and unit testing-> implement -> integration and system testing -> operation and maintenance
- The main drawback of the model is the difficulty of accommodating change after the process is underway, and so real projects rarely follow it
- Difficult to establish all requirements explicitly, no room for uncertainty (customer uncertainty, ambiguous requirements, evolving requirements)
- Customer must have patience as it may be near end of process before software is delivered, not fast enough for delivery of modern internet based software
- Major mistake can be disastrous (software works but does wrong thing, not really what customer needed)
- inflexible partitioning of the project into distinct stages
- difficult to trace requirements from analysis model to code
- this makes it difficult to respond to changing customer requirements
- this model is only appropriate when the requirements are well understood
- It is a systematic series of steps
- Each step is well defined
- Each step creates a definite product
- The correctness of each step can be carefully checked
An extensible framework which should be customized for specific organizations or projects. Iterative and incremental. Production quality software is released in piecemeal with each iteration.
- it is iterative and incremental, although most iterations will include work in most of the process disciplines, the relative effort and emphasis will change over the course of the project
- it is use case driven
- architecture centric
- risk focused
Structure:
- Four phases
- nine workflows or activities
- deliverables
- milestones
Four phases:
- Inception
- Elaboration
- Construction
- Transition
- establish business rationale
- decide project scope
- get commitment from sponsor to proceed further
- range from couple of hours chat and spreadsheet plan to a serious feasibility study over a couple of months
- collect more detailed requirements
- do high level analysis and design
- establish baseline architecture
- project planning
- to analyse the problem domain
- establish a good architectural foundation
- develop the project plan
- eliminate high risk elements
- define, validate and agree the architecture as quickly as possible
- agree the vision that came from the inception phase
- agree to a plan for construction phase
- key phase for iteration which can be in any phase
- each iteration builds production-quality software which is tested and integrated and which satisfies a subset of the project requirements
- all remaining components and application features are developed and integrated into the product
- all features are tested thoroughly
- emphasis is placed on managing resources, controlling operations to optimise cost, schedules and quality
- parallel construction can accelerate the availability of deployable releases
- categorise the use cases
- customer divides use cases according to business value
- developers divides use case according to risk
- developers estimate time for each case to nearest person-week
- high risk use cases involving a lot of project time may require more elaboration
- minimize development costs by optimizing resources and avoiding unnecessary scrap and rework
- achieve adequate quality as rapidly as possible
- achieve useful versions as rapidly as practical
- beta testing
- performance tuning
- user training
- user documentation
An interface in UML is a named set of operations and is shown as a stereotyped class
<< interface >> priceable. Generalization can be defined between interfaces
A class realizes an interface if it provided implementations of all the operations. In Java we say it implements an interface. UML provides two equivalent ways of showing this relationship.
A class can be dependant on an interface. This means that it only makes use of the operations defined in that interface. Ball and socket notation.
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.
A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interfaces. Modular programming is closely related to structured programming and object-oriented programming, all having the same goal of facilitating construction of large software programs and systems by decomposition into smaller pieces.