Revision Session 4

Systems and Software Design

Software Design-related Topics

• What are the key characteristics of a quality software design and how can they be achieved?

• What is meant by coupling and cohesion and how can addressing these concepts help improve the quality of a software design? How can these principles be applied in the detailed design of a system?

• Explain how a layered approach to software design can make software more portable, flexible and extensible.

What are the key characteristics of a quality software design?• Functional – does what is required• Efficient – in terms of time and resources• Economical – in terms of money and system resources• Reliable – hardware/software failure, data integrity –

testing important here• Secure• Flexible – configurability, modifiability• Portability- easy to adapt to different platforms• General – is the system general purpose?• Build-able- easy to code and build• Manageable• Maintainable- easy to fix, change, adapt• Usable- easy to use, can achieve desired goals, efficient• Re-usable- code can be re-used easily

How can they be achieved?• Functional – good analysis and user

communication, acceptance testing• Efficient/Economical – good analysis to ensure

clear requirements, effective coding practices• Reliable – clean design means easy to test

different types of testing: black box, white box, acceptance, etc.

• Secure – rigorous analysis to ensure that security requirements are identified– threat modelling when testing code.

• Flexible – configurability, modifiability: Code design that is component-based, layered

• Portability- easy to adapt to different platforms – design so that upper layers only need to know interface of lower layers (encapsulation).

• General – is the system general purpose- inheritance, configuration files?

• Build-able- easy to code and build- well designed, low coupling, cohesive

• Maintainable- easy to fix, change: clean code, low coupling and strong cohesion limits side-effects of change.

• Usable- easy to use, can achieve desired goals, efficient- user interface design/HCi

• Re-usable- code can be re-used easily- designed as components with clear interfaces, provides services e.g. Web services. Frameworks have re-usable class libraries

• What is meant by coupling and cohesion and how can addressing these concepts help improve the quality of a software design? How can these principles be applied in the detailed design of a system?

Basic Software Design Criteria: Cohesion• Cohesion is a measure of the degree to which

an element adheres to a single purpose. • Good cohesion –software modules ( sections

of code) carry out a clearly defined process or group of processes that are functionally related to one another.

• It does what it says on the tin … and nothing else.

Basic Software Design Criteria: Coupling– degree of interconnectedness or dependency

between modules.• Coupling should be minimal. • The aim is to produce modules which are

independent and can be amended without producing knock-on effects to the rest of the system.

Cohesion in an Object Oriented Design

• Cohesion is the extent to which a class or operation relates to a single purpose.

• Operation cohesion – degree to which an operation focuses on a single functional requirement.

• Class cohesion reflects the degree to which a class is focused on a single requirement.

• Specialisation cohesion – the semantic cohesion of inheritance hierarchies.

• Liskov Substitution Principle – should be able to treat a derived object as if it were a base object.

Coupling in an Object-Oriented Design

• Coupling is the interconnectedness between components.

• This is reflected by the number of links an object has and the degree of interaction an object has with other objects.

• Inheritance coupling describes the degree to which a subclass actually needs the features it inherits.

• Interaction coupling measures the amount of message types an object sends to other objects and the number of parameters passed with these message types.

How can addressing these concepts help improve the quality of a software design?

• Less dependence = easier to maintain, effect of change is localised

• easier to re-use as modules are more stand-alone

• easier to discover errors- code is easier to read, effect of errors is localised.

Architecture Considerations

• Coupling and cohesion can also be applied to packages.

• Classes are often divided into packages which denote subsystems.

• Packages are particularly useful for testing.

Packages and Dependencies

• The aim here is to ensure the system remains robust in the face of changing requirements.

• Organise classes into packages in such a way that change is localised.

• Show dependencies between these packages e.g. if a class in one package uses or is related to an object in another package this must be shown in the package diagram.

Dependencies between packages• A dependency between packages exists if

changes to one package would have knock-on effects in another. These occur if a class :-– sends a message to another– has another as part of its data– mentions another as a parameter to an operation.

• If a class changes its interface, any message it sends may no longer be valid

• Obviously we aim to minimise dependencies

Example Agate (p246)• Packages mark out related but distinct

application areas: advert preparation, staff management, campaign management.

campaign managemen

tControl

staff management

advert preparation

User Interface

Package cohesion

The Release Reuse Equivalency Principle• The granule of reuse is the granule of release.The Common Closure Principle• Classes that change together are packaged together.The Common Reuse Principle• Classes that are used together are packaged together.

Coupling between packages

The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.

The Stable Dependencies Principle Depend in the direction of stability.

The Stable Abstractions Principle Abstractness increases with stability. Abstract classes are less likely to change.

Detailed design of code

• Aim: transfer analysis model into a design model for software construction and produce a complete specification of classes.

• concerned with the design of classes, objects and their interactions.

What is Detailed design of code?• Classes identified during analysis provide

detail on the business requirements of the system.

• Now we also need to think about the implementation architecture , the platform, the user interface and the storage of data.

• Add new classes to support inputs, outputs, processes and file or database structures. Many of these will be determined by the target implementation environment.

Detailed specification of attributes and operation signatures

• Decide the data type of each attribute• Decide how to handle derived attributes• Add primary operations• Define operation signatures and parameter

types• Define the visibility of attributes and

operations.• Remember coupling and cohesion here

Class Attributes

• Attributes are typed either using a base type from the language to be used or a type available in a library e.g. Boolean, character, float, double, money, string, etc.

• Attributes will also have a specific visibility• Remember coupling – specify visibility of an

attribute on a “need to know” basis.• Derived attributes can be calculated from

others.

Essentially ...

• Maximise cohesion – design code where components are clear about what they do and map directly to domain objects.

• Minimise coupling – pass info on a need to know basis and reduce dependencies.

Layered Architecture Explain how a layered approach to software design can make

software more portable, flexible and extensible.

• We’ve already examined how we can partition our system into entity classes, interface classes and control classes in analysis.

• In design we can add further layers depending on the environment.

Example : 4-layer architecture

• User interface classes

• Control classes• Entity classes

• Lower level data handling classes

Domain Layer

Application LogicLayer

Data Management

Layer

PresentationLayer

BusinessLogicLayer

• Can use principles of coupling and cohesion with packages ( as above) to minimise dependencies.

• Portability enhanced as business model seperate from interface and database

• More flexible and extensible as change is localised.

User Interface and Database Design

• Outline four basic user interface design guidelines.

User Interface Design Guidelines

1. Consistency – helps a user learn an application and apply what they know across different parts of that application.

Guidelines in corporate style guides help here (e.g. Microsoft UX).

User Interface Design Guidelines

2. Appropriate User Support- when the user does not know what action to take or has made an error.

User Interface Design Guidelines

3. Adequate Feedback Show the user what is happening e.g. cursor position, eggtimer, progress monitor, status bar, highlighting, boxing.

User Interface Design Guidelines

4. Minimal User Input • use of codes and abbreviations• selecting from a list rather

than typing in a value• not having to enter information

that can be derived automatically, using default values.

• Key combinations can be used to speed things up for expert users.

• Discuss and give examples of different approaches that can be used to design the user interface.

Approaches to design

• Structured – uses task hierarchies e.g. STUDIO: task hierarchy diagrams, knowledge representation grammars, task allocation charts, state machines.

• Ethnographic – detailed qualitative study of users and tasks

• Scenario-based - draw out storyboards of scenarios , or describe them textually.

Aspects of all approaches can be combined.

1. Structured UI Design: Stages1. Requirements gathering

1) determine the types of user, frequency of use, task experience level, computing skills etc.

2) Determine task characteristics : complexity, breakdown, goal, context, task environment

3) Constraints, objectives, hardware, software, desired throughput, acceptable error rate

2. Interface design – allocate elements of task to user/system, determine communication requirements, design interface elements to support communication.

3. Interface evaluation – develop prototypes and test on users.

Task Hierarchy Breakdown

*

oo

Sequence

Selection

Repetition(iteration)

Example

Show Flights available

Enter Flight details

Book Flight

Take Payment

ConfirmBooking

Existingcustomer

New Customer

O OShow flights and prices

*

AbandonSelect flightO O

State Machines

Notation for state machine diagrams

–Each node is known as a vertex- black dot for start- arrows denote transitions and triggers can be specified for these

- - a state is a rounded box

- circled black dot for endstate

Ethnographic Approaches

• Qualitative assessment of task situation where the designer works very closely with the user in their work context.

• Observing• Listening• Asking questions• Interviews E.g. Participative design

Scenario-based Approaches

• Step-by step descriptions of user actions showing how users can achieve a goal

• Can use textual narrative or storyboards.

• How would you go about the detailed (code) design of the user interface of a system to be implemented in a C# environment?

1. Model interaction with the user, following basic user interface design principles.

2. Consolidate robustness diagrams if more than one use case is to be accessible via the same interface. There might also be a need to add some more classes e.g. to make the system more usable.

3. Select environment (wpf etc.) and check the style guidelines for interaction (Microsoft Windows UX)

4. Design an interface class. The types of attributes can correspond to the user interface components in the c# environment (e.g. using Windows forms or wpf -. listbox, label textbox etc. )

5. Sequence and state machine diagrams can be used to design more detailed interaction. These also help clarify boundary class methods.

6. Boundary classes can also include reports and these can be shown on sequence diagrams as well.

7. UML package dependency diagrams can be used to show how class diagrams can reference classes from reusable class libraries.

8. Prototypes can be built in the chosen environment and evaluated and tweaked to get an optimal design. If the UI class prototypes have been well designed the classes can then be used as part of the actual system.

What is meant by persistent data? What different ways can persistent data be stored?

• Persistent data is data which survives after a piece of software is no longer running. It is typically stored in a file or a database, depending on the quantity and nature of the data.

• Can be stored in files, different types of database. Files are appropriate for simple programs and data that does not need to be shared by many users.

FilesFile and Record Structures• Fixed – variable length records• Header/body structures of files e.g. daily transactions• Tagged data e.g. XML files

File types• Serial – update by adding at the end e.g. transaction

files • Sequential – ordered – need to partially rewrite file to

insert records.• Random access- can insert anywhere

File Access Modes• Serial• Indexed Sequential• Direct access • Hashed addressing

Types of File• Master File• Transaction Files : record business transactions/events e.g.

sales transactions, banking transactions• Temporary or work files• Parameter files used for e.g. configuration, settings etc.

Database Models• Relational databases – RDBMS – most commonly used

for record-based business applications.• Based on records or relations (rows), between

fields(columns), in tables• relational algebra is used to extract data • SQL is the standard query language e.g. SQL server, MySQL

• Object oriented Databases – used more for e.g. CAD systems. E.g. ObjectStore

• Object- Relational hybrids e.g. relational databases with OO extensions e.g. PostgresSQL

Describe, using examples, one method of database design.

• E-r modelling, normalisation

Normalisation

Aim : to reduce redundancyFunctional dependency between elements

should be 1-1• 1NF – atomic values• 2NF – every nonkey element is fully

dependent on the primary key• 3NF – attributes depend on the primary key

and nothing else.

Entity- Relationship Modelling

• Identify entities and attributes

• Remove multivalued attributes• Resolve many-many relationships

• Should produce normalised data