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

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

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?

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

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

Example Class 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 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

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.