Detailed Code Design

Ref ch 14 – Bennett et al

Job description for .net developer

• Strong understanding of OO design principles and design patterns

• Drive to participate in an Agile Development team, taking pride in writing Clean Code

• Knowledge of design techniques such as DI/IoC, SOLID, DDD

• System design models refine analysis models by adding system environment or solution domain details and further refining and adding detail.

• At this point the analysis model should have been verified and validated using walkthroughs and other techniques.

Questions to ask

• Are all classes/operations/attributes necessary?

• Are any missing?

• Optimise the design through factoring out common code using inheritance and composition.

Architecture Considerations

• To simplify the next step, classes are often divided into packages which denote subsystems.

• Rule of thumb: use packages when your class diagram for the system is bigger than an A4 page.

• Packages are particularly useful for testing.• We also need to consider our development

environment here.

Dependencies• 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

Layered Architecture

• 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

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.

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.

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 design of code considers• Frameworks - reusable set of libraries or classes

for a software system e.g..net includes classes, interfaces, and value types• Class Libraries e.g. .net Framework class library is

a library of classes, interfaces, and value types that provides access to system functionality

• Components - provide reusable code in the form of objects.

• We will focus later on user interface and data management design

• BUT – we also need to ensure that all our classes are well designed

All design principles are derived from 2 Basic Principles. What are they?

• Does what it says on the tin?• Need to know basis?

• We need to remember some of these when detailing our design.

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.

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.

Visibility

+ Public directly accessible by all

- Private visible to the object itself

# Protected visible to object and descendants

~ Package visible to classes in the same package

Operation signatures• Each operation needs to be specified in terms

of the number and type of parameters it passes and its return type (signature) e.g.

lodge(amount:money):boolean

e.g. if (myacc.lodge(500)) { ……} else {…..}

Class bankaccount-accountno:string-balance:money =0.00

+open(initialbal:money, accno:string)+getbalance():float+withdraw(amount:money):boolean+lodge(amount:money):boolean+close()

Note that you can specify initial values

Why use boolean as a return type?

Class depositaccount:bankaccountoverdraft_allowed:Moneyinterest_rate: Percentage/availablebal:Money/amountoverdrawn:Moneychargeinterest(period:time)checkoverdrawn():boolean

Derivedattributes

Should we show primary operations on a class diagram?• get, set, constructors, destructor –

sometimes it can be assumed these are available so no need to specify unless they specifically need to be publically visible e.g. you might need more than one constructor.

• There should be a standard for a project regarding this as opinions differ as to their necessity.

• C# has explicit destructors with the same name as the class with a ~ at the beginning.

• It is automatically called by the garage collector when the object ceases to exist.

• C# has properties which can implement get and set operations. We’ll examine these in the practical.

• Attribute declarations can also specify multiplicity – this can be done using square brackets (like an array declaration e.g. qualification: String[0..10]

Interfaces

• If a class can present more than one external interface to another class e.g. – only some classes can do certain things like change certain attributes – then the interface construct is used to show this.

Associations

1-1 Association

• Need to analyse the message passing between the objects tied by the link.

• See which direction messages are sent to see which object should contain the reference to the other object.

• We need to be careful about coupling here

ExampleClass gamestate Class screenmanager

Associations

1-Many Associations

• Need to analyse the message passing between the objects tied by the link.

• See which direction messages are sent to see which object should contain the reference to the other object.#

Example

• A campaign has a collection of adverts. • An invoice is for a collection of products• A student has a list of modules that they’re

enrolled in

• This can be done by including the collection in the class, but it is better sometimes to use a collection class to do this.

Class student-ID: string-Name :string-Mymodulelist:enrollist

Class enrolmentModulecode:stringDate registered:dateResult:float

Class enrollist-mymodules:enrolment[6]-/averagemark: floatFindfirst()Getnext()Addmodule()removemoduleIO

Many- Many Associations

• Again, collection classes can be used.

• Many languages provide collection classes predefined (e.g. list, queue, array etc.). See if you can find what collection classes are available in c# - what are their operations?

Example : product list in C#public class Productlist{

private List<product> products;public Productlist(){

products = new List<Product>();}public void Add(Product p){ products.Add(p);} public Product GetProduct(int i){ return(products[i]);}

...}

Integrity Constraints

• Referential integrity – an object identifier refers to an object that exists

e.g. What to do if an assigned staff member to a campaign leaves?

• Dependency constraints - attribute dependencies where one attribute depends on others need to be maintained.

• Domain integrity – attributes only hold permissible values.

Designing Operations

Determining the best algorithm to perform the required function.

5 Principles of Class Design(SOLID)

Single Responsibility Principle• A class should have one, and only one, reason to change.Open Closed Principle• You should be able to extend a classes behavior, without

modifying it.Liskov Substitution Principle• Derived classes must be substitutable for their base classes.Interface Segregation Principle• Make fine grained interfaces that are client specific.Dependency Inversion Principle• Depend on abstractions, not on concretions.

Inversion of Control /Dependency Injection• How do we get the enrolments into the

student?• How can we ensure that the enrolment class is

independent from the student class?• IoC/DI :Make sure that the student class is not

responsible for creating the enrolment objects.

• – we “inject” each enrolment into the list, and create it separately.

Principles of IOC

Don’t call us we’ll call you• Main classes aggregating other classes should

not depend on the direct implementation of the aggregated classes.

• Both the classes should depend on abstraction either using interface or abstract class.

• Abstraction should not depend on details, details should depend on abstraction.

• "Instead of a component being responsible for getting the required dependencies to perform a task, a container/factory should build and inject the dependencies into the component. Then the component can perform the sole activity for which it is responsible. The component need not care about from where it got its dependencies. Then the components code will be much more cleaner and testable".

DDD- Domain-driven design

• approach to developing software for complex needs by connecting the implementation to an evolving model of the core business concepts

• project's primary focus -core domain and domain logic

• creative collaboration between technical and domain experts to cut closer to the conceptual heart of the problem

Essentially ...

• Model software on the user domain• Ensure agreed set of semantics• Minimise coupling• 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.