1. Detailed Code Design
Ref ch 14 – Bennett et al

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

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

4. Questions to ask Are all classes/operations/attributes necessary?
Are any missing?
Optimise the design through factoring out common code using inheritance and composition.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19. 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 {…..}

20. Why use boolean as a return type?
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?

21. Class depositaccount:bankaccount
overdraft_allowed:Money
interest_rate: Percentage
/availablebal:Money
/amountoverdrawn:Money
chargeinterest(period:time)
checkoverdrawn():boolean
Derived
attributes

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

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

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

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

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

27. Example
Class gamestate
Class screenmanager

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

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

30. Class enrollist
-mymodules:enrolment[6]
-/averagemark: float
Findfirst()
Getnext()
Addmodule()
removemoduleIO
Class student
-ID: string
-Name :string
-Mymodulelist:enrollist
Class enrolment
Modulecode:string
Date registered:date
Result:float

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

32. 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]);
...}

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

34. Designing Operations
Determining the best algorithm to perform the required function.

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

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

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

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

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

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