SCC204

Requirements Definitions stage

– Establishes what the proposed software system will do

– Describes what services the system will provide and the constraints under which it will do so.

Software design stage

concerned with identifying sub-systems and components, that will deliver the specified requirements.

implementation and unit testing stage

– Simply integrates units into larger units and tests them

– Eventually the software goes into operation, and system maintenance comes into play as the business goals, user requirements or technology evolves.

Why may the processes in the software engineering life cycle revisit previous development stages?

– It is likely that the user requirements or business goals may change

– Aspects of the system requirements may also become clearer with time.

What is a software requirement?

– A description of what the system under development or proposed system should do and any constraints under which it must do it.

– It focuses on what the system will do, not how it will do it

– It serves as a contract between the development team and the customer

Guidelines for writing requirements

– Use language in a consistent way

– Use shall for mandatory requirements

– Use should for desirable requirements.

– Use text highlighting to identify key parts of the requirement.

– Don’t make assumptions about the reader’s knowledge.

– Involve as many stakeholders as possible

– Include an explanation (rationale) of why a requirement is necessary.

Functional Requirements?

FR are requirements for services that a system should deliver.

Non-Function requirements

– NFR specify the quality with which a system delivers its services. Typical examples include: speed, size, Ease of use, Reliability, Robustness and profitability.

– NFRs are SHALL statements that precisely specify these constraints

Stakeholders

You need to identify the important stakeholders in a system to discover their requirements

– System stakeholders: Any person or organisation who is affected by the system in some way and so has a legitimate interest

– End users of the system

Why are requirements managed?

– Requirements beget requirements …

– We want to track them

– We might have to reappraise the requirements

– Requirements change

What happens when requirements are wrong?

Systems are late, unreliable and don’t meet customer expectations

Benefits of use cases?

– Offer a a way to structure requirements according to stakeholder needs/goals.

– They are mainly textual so easy to use as a way to communicate between different stakeholders

– They are a standard part of the Unified Modelling Language

– They describe “scenarios” or sample execution scenarios for the system under development, which are easy to understand.

What is a Behavioural model?

It describes how a system responds to stimuli from “outside” of the system.

An Actor

– A user, system or device that interacts with the system being developed

– Primary actors on left side

– Secondary actors on right side

A Use Case

– Represents a high level goal that user wants to achieve

Preconditions in use case?

Activities that must take place, or any condition that must be true, before the use case can be started.

i.e. - 1)Student has been issued with the coursework

2) Student has attempted the coursework.

Flow of events in use case?

– User actions and system responses that will take place during execution of the use case under normal conditions.

– May include alternate flows that describes a scenario other than the basic flow that results in a user completing or achieving their goal.

Postconditions in use case?

State of the system at the conclusion of the execution with normal flow of events

i.e. - 1)Student receives mark.

2) Student’s mark is recorded.

What is the purpose of Include in use case diagrams?

– Include is used to extract use case fragments that are duplicated in multiple use cases (i.e., common mandatory behaviour such as accepting TOS when creating an account).

– Arrows faces towards what is being included.

What is the purpose of Extend in use case diagrams?

– Extend is used when a use case conditionally adds steps to another use case (i.e., optional behaviour such as editing privacy settings while creating an account or mail subscription settings)

– Arrows faces away from what is being extended.

Alternatives in use case?

different ways to fulfil the postconditions such as initially setting that user privacy setting aren’t edited but an alternative is that the user does edit it.

Exceptions in use case?

cannot fulfil the postconditions such as not being able to validate personal information to create an account.

Use case Guidelines

– Avoid Excessive Structuring

– Avoid Functional Decomposition

– Understand the difference between include and extend

– Only use when absolutely necessary

Use case- Cloud Level detail

– Very high level summary

– Typically a business goal

– Example is selling books online

Use case- Sea Level detail

– Single sitting

– User gets a result

– Example is buying a book

Use case- Fish Level detail

– Usually the include or extend use cases

– Example is Login

Use case- Bottom-of-the-ocean Level detail

– Too low!

– Check password

What is UML?

Unified Modelling Language is a commonly accepted way to visualise the design of a software system.

Why use UML?

– OOP design patterns are typically drawn using class diagrams

– Easier to fit more information in less space (e.g. compared to code)

– Fast to create and reason about

How do you indicate if a field/method is private or public

private/protected : -

public : +

Conceptual perspective of class diagrams?

focus on domain concepts, e.g. Bank, Account, ATM

Specification perspective of class diagrams?

focus on the interfaces of Abstract Data Types (ADT)

Implementation perspective of class diagrams?

focus on implementation details

Association

Association just shows that two classes need to communicate with each other.

Aggregation

– Aggregation implies that a class can exist without another class

– Example is a Person can exist without Company

Composition

– Composition implies a class can’t exist without another class

– Example is a Room can’t exist without a house

Generalisation(Inheritance)

– Abstract classes allow programmers to define methods without implementing them.

– All derived classes are then forced to provide implementations for these methods.

– Abstract classes and methods are italic.

– Extends relationship is used between the abstract class and its derived class (empty triangle from derived towards abstract class)

What are the two types of generalisation(Inheritance)?

– Interface inheritance which is achieved with the use of interfaces.

– Implementation inheritance only if you want to reuse all methods (operations) of the parent class and add some extra methods to the derived class.

Interfaces in class diagrams

– Contain only method signatures that describe the behaviour of a class (i.e. what behaviour a class needs to provide)

– Class can implement multiple interfaces (i.e. a class can have multiple behaviours)

– Class must match method signatures of all interfaces which it is implementing ( Any class inheriting from interface must have all the methods the interface has).

– The relationship is drawn by an empty triangle from implementation class to the interface class and with a dash lines instead of straight lines.

Benefits of Interfaces/abstract classes?

– Enable (dynamic) polymorphism

– Reverse source code dependencies

– Separate operations (important) from their concrete implementations (less important)

– Form part of almost every software design pattern

Multiplicity

– 1 : Exactly one

– 0..1 : Zero or one

– \* : Many

– 0..\* : Zero or many

– 1..\* : Zero or many

How to determine a relationship in class diagram?

– Is the class a subclass of another? If so, the relationship is generalisation (inheritance).

– Is the class part of another? If so, the relationship is aggregation or composition.

– Does the class interact with another? If so, the relationship is association.

What are SOLID principles?

Tells us how to arrange our functions and data structures into classes and how those classes should interconnect.

What is SRP?

– The Single Responsibility Principle in which a module should be responsible to one, and only one, actor.

– A good general solution is to separate code that supports different actors (i.e. decouple)

What is Coupling?

Coupling is when a module is responsible to more than one actor so a module change where methods can be the source of change can affect all actors that it is responsible for and cost a lot.

What is OCP?

– The Open-Closed Principle where Classes should be open for extension but closed for modification

– Modifying a class increases risk of breaking already working code

– An example is extending a class to an interface and allowing new classes to inherit from the interface.

What is LSP?

– The Liskov Substitution Principle states out that if you have a group of similar objects, you should be able to use any one of them without causing problems.

– An example is a square inheriting from rectangle violates LSP as rectangle would have two methods setting width and height whereas a square has to only set the side so you can never use square as a substitute for rectangle where it is expected to be similar. So to not violate it you make rectangle and square inherit from a shapes class instead of square inheriting from rectangle.

What is ISP?

– Interface Segregation Principle that a client shouldn’t depend on methods they don’t use.

– An example is when multiple clients rely on a method that is in a class but don’t require the use of the other methods. So you can use interfaces for each method and let clients that require a specific method use that specific interface with the method.

The original class can inherit from the interface and so no recompiling needs to take place.

What is DIP?

– Dependency Inversion Principle is where flexible systems are those in which source code dependencies refer only to abstractions and not concrete implementations.

– Don’t refer to volatile concrete classes, Don’t inherit from volatile concrete classes, Don’t override concrete functions, Avoid mentioning the name of anything concrete and volatile

– An example is a class requiring to change what it is using and so extra changes need to take place in the class, Instead an interface can be used so you refer instead of having a concrete variable reference.

Software Architecture

– The software architecture of a system is a set of structures needed to reason about the system, which comprise software elements, relations amongst and properties of both

– Software elements may be software sub-systems or components

Architectural design

The sub-systems making up the system and their relationships are identified and documented. Model of control is identified.

Interface design

– For each sub-system, it’s interface with other sub-systems is designed and documented.

Component design

– services (i.e. functional requirements) are allocated to different components and the interfaces of these components are designed.

Steps in Architectural design

1) System structuring - the system is structured into a number of principal sub-systems or components and the communication between sub-systems is identified.

2) Control modelling - a general model of control relationships between the parts of the system is established.

3) Modular decomposition - each sub-system is decomposed into modules.

Steps involved in identifying sub-systems and their interfaces?

1) Identify major functions the system is required to do (i.e. Alarm system notifies local authorities and owner)

2) List the system functions(sense intruders, activate siren, notify local authorities, activate video, message home owner)

3) Group related functionality ( Sensor, siren , video relay, video, message)

4) Associate functionality of sub-systems

5) For each sub-system establish if there is need to partition further

Elements involved in specifying sub-system interfaces

– Interface name( I in front convention for interface)

– Operations : What it does

– Input: What input it expects

– Output: what output is expected

– Exceptions: What cause invalid input

What does the ball represent in the ball and socket diagram?

Ball represents the service provider for example an application needs a database to utilise its functions, then there would be a ball arrow from the database to the application.

What does the socket represent in the ball and socket diagram?

The socket represents the service user or caller for example the database is the provider by having a ball arrow go from database to the app but the app is the caller and so it would have a socket going from it to the database.

Centralised control between subsystems

– One sub-system has overall responsibility for control.

– Call-return model for sequential systems.

– Manager model for concurrent systems where it can control the stopping, starting and coordination of other system processes.

Event-driven systems

– Each sub-system can respond to externally generated events from other sub-systems or the system’s environment.

– The two principal even-driven models are Broadcast models and Interrupt-driven models.

Broadcast models in Event-driven systems

– An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so.

– Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event (publisher-subscriber pattern).

– Control policy is not embedded in the event or message handler so sub-systems decide on events of interest to them.

Interrupt-driven models in Even-driven systems

– Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing.

– There are a known number of interrupt types with a handler defined for each type.

– When an interrupt of a particular type is received, a control is transferred to its handler.

Architectural styles

– Specific templates which are general and reusable:

* Template for structuring system architectures
* Each template can be used for different types of software
* Stylised description of good design practice which has been tried and tested
* include information about when they are and when they are not useful

What system quality properties(i.e. NFR) can be affected by choice of architectural style?

Performance : Localise critical operations and minimise communications. Use large rather than fine-grain components

Security : Use a layered architecture with critical assets in the inner layers

Safety : Localise safety-critical features in a small number of sub-systems

Availability : Include redundant components and mechanisms for fault tolerance

Maintainability : Use fine-grain, replaceable components

Limitations on system qualities by choice of architectural style

– Using large-grain components improve performance but reduces maintainability

– Introducing redundant components improves availability but makes security more difficult

– Localising safety-related features usually means more communication so degraded performance

– Small-grain components improve reuse but degrade performance

Input-process-output architecture

– In many cases software components have some input, business logic, and output.

– A controller is needed to handle the input and orchestrate the business logic an example is:

* User performs an action which is transferred in a request model via a delivery mechanism
* Interactor receives the request model through an input boundary
* Interactor decides which actions to take based on the request model and executes entities accordingly
* Interactor generates a result model and prepares to send it across the boundary back to the user
* Finally, the response is transferred through the boundary to the user

Architectural boundary

– Well defined boundaries are fundamental to architectural design:

* Enable separation and independence between sub-systems (e.g. UI and business logic)
* Make maintenance, deployment and testing simpler and faster

Benefits of Input-process-output architecture

– Business logic is decoupled from the presenter (UI)

* If UI changes or breaks, business logic won’t be affected
* UI can be replaced with virtually anything
* Business logic can be tested without the need of UI
* Tests can run fast and independently

Plug-in architectural style

Plug-in is a component that provides some service within the overall system, Plug-in depends on the system and not the other way around, and an example is:

* The output to the user or UI can be changed to different things such as web or tests can be virtually anything.

Benefits of Plug-in architectural style

System is extensible and modular

Limitations of Plug-in architectural style

– When developing a plug-in architecture it is important to consider what actions plug-ins are allowed to do so security is at risk.

– Changes to the system interface which can break the plug-in.

Layered architectural style

– Number of layers is arbitrary

– Each layer only relies on the facilities and services offered by the layer immediately beneath it

– Architecture is changeable and portable so long as interfaces stay unchanged

– Each layer can be developed by different teams independently

Benefits of Layered architectural style

– Allows replacement of entire layers so long as interface is maintained.

– Redundant facilities (i.e. authentication) can be provided in each layer to increase dependability of the system

Limitations of Layered architectural style

– Performance can be hindered because of multiple levels of interpretation of a service request as it is processed at each layer.

– High level layers may have to directly communicate with low level layers without the one beneath it.

Repository architectural style

– All data in a system is managed in a central repository that is accessible to all the system components.

– Components don’t interact directly, only through the repository.

Benefits of Repository architectural style

– Components can be independent- they don’t need to know the existence of other components

– Changes made by one component can propagate to all components

– All data can be managed consistently for example backing up can be done at the same time.

Limitations of Repository architectural style

– The repository is a single point of failure so problems in the repository affect the whole system

– Maybe inefficiencies in organizing all communication through the repository

– Distributing the repository across several computer can be difficult.

Client-server architectural style

In this architecture, the functionality of the system is organized into services, with each service delivered from a separate server. An example is multiple clients using internet protocols to access different servers such as web server, video server, picture server and etc.

Benefits of Client-server architectural style

– Servers can be distributed across a network.

– General functionality can be available to all clients and doesn’t need to be implemented by all services.

Limitations of Client-server architectural style

– Each service is a single point of failure so susceptible to denial of service attacks or server failure.

– Performance maybe unpredictable because it depends on the network as well as the system

– May have management problems if servers are owned by different organisations.

State Machines

Models dynamic behaviour, specifying the sequence of states that it goes through during it’s lifetime in response to events.

State

Condition object stays in for some time, during which it behaves in the same way but may respond differently to the same trigger event in different states.

Transition

From one state to the next; may have a trigger, a guard and an effect.

Trigger

External, instantaneous stimulus; a signal, an event, a change in some condition, or the passage of time.

Guard

A condition which must be true in order for the trigger to cause the transition.

Event

An action that occurs as a result of the transition.

Event Types:

– Signal event: Receipt of a signal e.g., sendSMS(message)

– Call event: Operation call e.g.,

occupy(user, lectureHall)

– Time event: Time-based state transition where relative is based on time of the occurrence of the event e.g., after(5 seconds) and absolute is when(time == 16:00)

Composite States

– State machines can be nested, so that we can hide a submachine/sub state at some level of abstraction.

– Sub states can be shown in place, or hidden with use of composite icon.

Concurrent States

– If a composite state machine has two or more regions, their submachines operate concurrently.

– State of object is pair (or tuple) of sub states.

– Entry and exit can be synchronized by fork and join.

An example of concurrent state is applying breaks and having applyfrontbreak state and applyrearbreakstate operate concurrently and then stop applying breaks.

How to build state diagram

1\. Identify the events that affect an object

2\. Identify the possible different states, including start and stop states

3\. Check whether events are conditional

4\. Identify any actions the object performs in response to an event

5\. Begin the diagram from the start state

6\. Build the diagram systematically through events and states

7\. Check for super states/composite states

What other types of dynamic UML diagrams exist other than state machines?

– Activity diagrams : used to model the flow of control.

– Sequence diagrams : used to specify interactions in the system

Interfaces

– Powerful tools for reducing dependencies in code

– Allows client objects to be unaware of:

* the specific classes of objects they use,
* and the classes that actually implement these interfaces

– To describe peripheral abilities to an object not central to its identity

An interface can’t be extended but only realised(implemented) through the use of dash lines and open arrowhead.

An interface can extend another interface.

Design Patterns?

– Software design patterns are reusable solutions to common problems that occur in software development.

– They capture the experience of experts in a form that others can reuse.

– They represent proven solutions to recurring software design problems and embody best practices.

4 Elements of design pattern?

– The pattern name is a handle we can use to describe a design problem and its solution in a word or two

– The problem describes the context and when to apply the pattern

– The solution describes the elements that make up the design, pattern their relationships, responsibilities and collaborations. The pattern does not describe a concrete solution.

* Textual, diagram (UML), source code

– The consequences are the result and trade-offs of applying the pattern

Categories of design patterns

– Creational

* Class instantiation
* Abstract Factory, Builder, Factory Method, Prototype, Singleton

– Structural

* Class and Object composition
* Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy

– Behavioural

* Communication between objects
* Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor

The Observer pattern

a behavioural design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the objects that they are observing. Subject is independent from observers.

An example is a motion sensor being a subject and the observers being the siren that gets notified and starts ringing.

Structural Pattern: Adapter

The Adapter structural design pattern that converts the interface of a class into an interface that a client expects

* Client collaborates with objects conforming to the Target interface.
* Target defines the domain-specific interface that Client uses.
* Adapter adapts the interface Adaptee to the Target interface.
* Adaptee defines an existing interface that needs adapting.

Structural pattern: Class Adapter

– Adapter adapts Adaptee by inheriting from it and implementing the Target interface

Structural pattern: Object Adapter

– An object adapter relies on object composition

– Adapter implements the Target interface and contains the Adaptee instance to which it forwards requests

Structural Pattern: Proxy

• A proxy object provides a surrogate or placeholder for another object in order to control access to it

– The proxy pattern involves creating a proxy class that implements the same interface as the class that it is standing-in for

– The proxy class stores an instance of the class that it is standing in for. – The proxy then forwards requests to the real object

– Clients simply access the proxy