1. Revision Session 4 Systems and Software Design

2. 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.

3. 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

4. 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.

5. 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

6. 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?

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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

15. Example Agate (p246) Packages mark out related but distinct application areas: advert preparation, staff management, campaign management. campaign management Control staff management advert preparation User Interface

16. 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.

17. Coupling between packages The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.The Acyclic Dependencies Principle The Stable Dependencies Principle Depend in the direction of stability.The Stable Dependencies Principle The Stable Abstractions PrincipleThe Stable Abstractions Principle Abstractness increases with stability. Abstract classes are less likely to change.

18. 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.

19. 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.

20. 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

21. 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.

22. 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.

23. 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.

24. Example : 4-layer architecture User interface classes Control classes Entity classes Lower level data handling classes Domain Layer Application Logic Layer Data Management Layer Presentation Layer Business Logic Layer

25. 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.

26. User Interface and Database Design Outline four basic user interface design guidelines.

27. 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).

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

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

30. 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.

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

32. 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.

33. 1. Structured UI Design: Stages 1.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.

34. Task Hierarchy Breakdown * o o Sequence Selection Repetition (iteration)

35. Example Show Flights available Enter Flight details Book Flight Take Payment Confirm Booking Existing customer New Customer OO Show flights and prices * AbandonSelect flight OO

37. State Machines

38. 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

39. 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

40. Scenario-based Approaches Step-by step descriptions of user actions showing how users can achieve a goal Can use textual narrative or storyboards.

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

42. 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)

43. 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.

44. 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.

45. 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.

46. Files File 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

47. 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.

48. 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

49. Describe, using examples, one method of database design. E-r modelling, normalisation

50. Normalisation Aim : to reduce redundancy Functional 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.

51. Entity- Relationship Modelling Identify entities and attributes Remove multivalued attributes Resolve many-many relationships Should produce normalised data