SWEN30006 - Software Modelling and Design

Modelling

We use models to help understand systems. Use cases are a collection of related successes and failures that help to describe an actor in the system under discussion. An actor is something with behaviour within the model (e.g. person, computer, etc.)

Actors

There are 3 kinds

Primary: Has goals fulfilled by the system
Supporting: Provides a service to the system
Offstage: Has an interest in the behaviour but is not primary or supporting

Domain model

Model as an overview of the system.

Find conceptual classes
Create the classes in a UML diagram
Add associations and attributes

Only uses conceptual classes, i.e. ones which have a real world equivalent. Model doesn't need software specific requirements, such as databases or methods.

Associations are a line between two classes, with multiplicity denoted at each end and a name characterising the relationship written with the association. Associations need to be:

Significant in the domain
Have preserved knowledge of relationship

Design models

Defines software objects and their relationships. Sits in the application logic layer, connecting low level interfaces such as databases so they can be presented in high level interfaces like a UI.

Sequence diagram

Shows the sequence of events in an interaction between classes.

Design class diagram (Static model)

Shows a software level relationship between classes. This type of model descends from the domain model and aims to reduce the representational gap. Here we assign methods and software types. We may also introduce software-only classes and visibility notations.

Responsibility

Responsibilities are the contracts and obligations of a classifier. This can be through directly acting, invoking others or coordination. There also needs to be knowledge of private encapsulated data, outputs and other objects. This causes the design to be a community of collaborating objects and involves assigning responsibilities. We also aim for a low representational gap when assigning.

GRASP principles

A pattern is a recurring successful application of expertise in a particular domain. They can:

Capture expertise and make it accessible to non-experts
Facilitate communication among practitioners by providing a common language
Make it easier to reuse successful applications and expertise
Facilitate generating modified applications
Improve understandability
Simplify documentation

The General Responsibility Assignment Software Patterns (or Principles) (GRASP) is a set of ideas in software design. These are:

Creator
Information Expert
Low Coupling
Controller
High Cohesion

And to a lesser extent:

Polymorphism
Indirection
Pure Fabrication
Protected Variations

Creator

Who should be responsible for creating a new instance of some class?

Common activity, so useful to have a general principle. Want outcomes with low coupling, increased clarity, encapsulation and reusability.

If one of the following is true, we create a class (B) with the sole responsibility of creating instances of a class (A):

B “contains” or compositely aggregates A
B records A
B closely uses A
B has the initialisation data for A that will be passed to A when it is created. Here B is an expert for A's creation

If the creation involves significant complexity, it can be useful to delegate to a helper class, such as some type of factory.

Information Expert

What is a general principle of assigning responsibilities to objects?

Pools all the information about many classes to a central space.

Can result in poor coupling and cohesion.

Low Coupling

How to support low dependency, low change impact and increase reuse?

Coupling is a measure of how strongly one element is connected to, has knowledge of or relies on others. Assigning responsibilities to many classes so that coupling remains low is useful.

High coupling to stable elements is rarely a problem as they will not change and break the rest of the system.

High Cohesion

How to keep objects focused, understandable and manageable? And as a side effect support low coupling?

Cohesion is how strongly (functionally) related and focused the responsibilities of a class are. Important when assigning responsibility. Classes with low cohesion can be:

Hard to comprehend
Hard to reuse
Hard to maintain
Delicate, constantly affected by change

Low cohesion is sometimes needed for non-functional requirements.

Controller

What first object beyond the UI layer receives and coordinates (“controls”) a system operation?

This deals with major input events and appears on sequence diagrams. A single class is created to work a “root” where the whole system is working with (facade). Alternately a class is created to deal with a particular event (use case or session).

Can end with a controller with too much responsibility, leading to low cohesion. Need to delegate to more controllers.

Polymorphism

How to handle alternatives based on type?

This is a fundamental theme in programs. Allows for pluggable software components. Solution is to use operations with the same interface, assigning responsibilities for the varying behaviour. This is as an alternative to using conditionals to select the alternative. Allows for a single interface to different entity types.

Can have problems with protected variations.

Pure Fabrication

Which object should have responsibility when solutions are offered by (e.g.) expert violate high cohesion and low coupling?

Assign a highly cohesive set of responsibilities to a class not in problem domain. Created to support other software aims but has no representation in itself. Justifies increasing representational gap for making other parts better.

Can be overused, driving to behavioural decomposition where functions are grouped into objects. Needs to balanced with representational decomposition. If poorly applied, can affect coupling.

Indirection

Where to assign a responsibility to avoid direct coupling between two or more software elements? How to decouple objects so that low coupling is supported and reuse potential remains higher?

Assign the responsibility to an intermediate object to mediate between other objects to avoid direct coupling. Creates indirection between objects.

Increases the complexity of a design which needs to be justified by lower coupling. Can improve performance by removal.

Protected Variations

How to design objects, subsystems and systems sot heat the variations or instability in these elements does not have an undesirable impact on other elements?

Need to identify points of known or predicted variation or instability and assign responsibilities to a stable interface. Allows for easy substitution of functionality. Allows for the open-closed principle - modules should be open for extension and closed for modification.

Costs of speculative future-proofing can outweigh benefits. It may be easier/cheaper to rework a simple, brittle design. Novices tend to brittle designs, Intermediate to overly general and Experts balance correctly.

State Machines

State machines describe the behaviour of an object in terms of events that affect the object and the state of the object between events. Here, an event is a significant or noteworthy occurrence and a state is a condition of an object at a moment in time. A transition is a directed relationship between two states such that an event can cause an object to change state.

A state dependent object reacts differently depending on state whereas a state independent object always reacts to an event in the same way.

State machines can be useful in modelling complex objects. Often used in communication and control applications, less in business information systems.

Guards

State transitions can require a guard as well as a trigger in order to transition between states. Denoted by trigger [guard] / action. The action is the output for the transition.

Choice pseudostates

Used to when the same trigger will transition to different states depending on the guard. Can have two or more outgoing transitions. Can also have a predefined else guard.

Gang of Four

The Gang of Four patterns come from the book “Design Patterns: Elements of Reusable Object-Oriented Software” and is so called as the book has four authors. The patterns can be grouped as follows:

Creational Patterns (5): Abstract the object initiation process
Structural Patterns (7): Describe how classes and objects can be combined to form larger structures
Behavioural Patterns (11): Most specifically concerned with communication between objects

Adapter

How to resolve incomplete interfaces, or provide a stable interface to similar components with different interfaces? Convert the original interface of a component into another interface through an intermediate adapter object.

An adapter appeals to the polymorphism, indirection and pure fabrication GRASP principles. Problems arise when deciding who creates the adapters and what class of adapter should be created. These can be partially answered when cohesion is considered.

Factory

Who should be responsible for creating objects when there are several considerations, such as complex creation logic, a desire to separate the creation responsibilities for better cohesion and so forth? Usage of a pure fabrication pattern called a factory that handles the creation solves this.

Problems arise in who creates the factory and how it is accessed as it may need to be accessed from many places. Often only a single instance is needed so how to get visibility into the object is a problem. The singleton pattern can help with this last problem.

Concrete Factory

Also known as a simple factory. Separates and hides complex creation logic into cohesive helper objects. Allows introduction of performance enhancing memory-management strategies, such as object caching and recycling.

Singleton

Exactly one instance of a class is allowed - it is a singleton. Objects need a global and single point of access. This is achieved with the use of a static method of the class that returns the singleton.

The whole class is not static as we may want subclasses, which are not allowed with static methods. Also sometimes it doesn't fit the context.

Strategy

How to design for varying, but related, algorithms or policies? How to design for the ability to change these algorithms or policies? We design each algorithm/policy/strategy in a separate class with a common interface.

Composite

How to treat a group or composition structure of objects the same way (polymorphically) as a non-composite (atomic) object? Define classes for composite and atomic objects so they implement the same interface.

Facade

Require a common, unified interface to a disparate set of implementations or interfaces - such as within a subsystem - is required. There may be undesirable coupling to many objects in the subsystem, or int implementation of the subsystem may change. What to do? Define a single point of contact to the subsystem, a facade that wraps the subsystem. This facade represents a single, unified interface and is responsible for collaborating with the subsystem components.

A Facade provides a simpler interface of a complex subsystem for a client class. A Controller handles user inputs based on logic and workflow. An Adapter wraps an API to a unified interface.

Observer

Different kinds of subscriber objects are interested in the state of changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event. Moreover, the publisher wants to maintain low coupling to the subscribers. What to do? Define a “subscriber” or “listener” interface. Subscribers implement this interface. The publisher can dynamically register subscribers who are interested in an event and notify them when an event occurs.

Decorator

How to dynamically add behaviour or state to individual objects at run time without changing the interface presented to the client? Encapsulate the original concrete object inside an abstract wrapper interface. Then lat the decorators that contain the dynamic behaviours also inherit from this abstract interface. The interface will then use recursive composition to allow an unlimited number of decorator “layers” to be added to each core object.

Architecture

Software Architecture is:

The set of significant decisions about the organisation of a software system
The selection of the structural elements and the interfaces by which the system is composed
Their behaviour as specified in the collaborations among those elements
The composition of these structural and behavioural elements into progressively larges subsystems
The architectural style that guides this organisation

Architectural analysis is concerned with identifying and resolving a system's non-functional requirements in the context of its functional requirements. This includes identifying and analysing:

Architecturally significant requirements
Variation points
Potential evolution points

It also reduces the risk of missing a critical factor in system design, focuses effort on high priority requirements and aligns the product with business goals.

Some architecturally significant non-functional requirements are:

Usability: Aesthetics and consistency of UI
Reliability: Availability, accuracy of system calculations and system's ability to recover from a failiure
Performance: Throughput, response time, recovery time, start-up time and shutdown time
Supportability: Testability, adaptability, maintainability, compatability, configurability, installability, scalability and localizability

Analysis consists of identifying architectural factors, being requirements with impact on architecture. For these factors, alternatives are considered to find the best for the current use case. For each factor, the following are recorded:

Factor
Measures and quality scenarios
Variability (current flexibility and future evolution)
Impact of factor on stakeholders, architecture and other factors
Priority for success
Difficulty or risk

Technical Memo

A technical memo records alternative solutions, decisions, influential factors and motivations for the noteworthy issues and decisions. What recorded consists of:

Issue
Solution Summary
Factors
Solution
Motivation
Unresolved Issues
Alternatives Considered

Layered architecture

A layer is a course grouping of classes, packages or subsystems that have a cohesive responsibility for a major aspect of a system. These layers are logical, being unconcerned with networking, physical or operating system architectures. Architectures can be strictly layered where a layer only calls upon the services on the layer directly below it, or relaxed layered where a higher layer can call upon several lower layers.

Layers are organised from high application specific to low general services. Higher to lower coupling is tolerated, lower to higher is avoided. Lower layers shouldn't show external resources.

Components

A component is a modular part of a system that encapsulates its contents and is replaceable within its environment. A component diagram concerns the implementation of the software system by providing initial architecture landscape. It defines the required behaviour and required interfaces.

DokuWiki

Table of Contents