2. QuestionHow to create software that is ? Easy to read and
understand Easy to change Easy to test
3. UML Unified Modeling Language The most basic of UML diagrams
is the Class Diagram. It describes classes and shows the
relationships among them.
4. UMLUML Notation for Relationships Inheritance class
Relations A generalizes B A B derives from A Class A {} B Class B :
A {}
5. UMLUML Notation for Relationships Association class
Relations A uses B A B Class field Methode parameter Methode Return
Type class A Local variable { void Methode1() { B var1 = new B(); }
}
6. UMLUML Notation for Relationships Aggregation class
Relations Shared Association A B A aggregates B B is part of A
class RelationsClass B {}Class A Airport Aircraft{B FieldB;}
7. UMLUML Notation for Relationships Composition class
Relations Not-Shared Association A B A is composed of BClass B {}
class RelationsClass A Person Leg{B FieldB;}
11. System-Quality Attributes Maintainability A measure of how
easy it is to modify the software to correct faults, improve
performance or other attributes. Flexibility A measure of how easy
it is to change software in response to different requirements
12. System-Quality Attributes Reusability the capability for
components and subsystems to be uses in other applications and in
other scenarios Readability A measure of how easy it is to read and
understand code. Testability A measure of how easy it is to create
test criteria
14. Code Qualities Encapsulation Cohesion No Redundancy
Coupling
15. Code Qualities Encapsulation Information hiding Means any
kind of hiding Encapsulation of data Encapsulation of methods
Encapsulation of type (behind an abstract class or interface)
16. Code QualitiesEncapsulation Type Encapsulation Polymorphism
class Encapsulation interface Cli ent IProduct ProductA Prod
uctB
17. Code Qualities Cohesion Cohesion refers to how much (or how
little) the internal parts of something are working on the same
issue No Redundancy Anything that could change should be in a
single place in the system
18. Code Qualities Coupling Coupling refers to the degree of
direct knowledge that one class has of another. Strong coupling
occurs when a dependent class contains a pointer directly to a
concrete class Loose coupling occurs when the dependent class
contains a pointer only to an interface that the concrete class
implements
19. Code QualitiesCoupling Strong/tight coupling class Coupling
Cli ent Conc rete Loose coupling class Coupling interface Cli ent
Abstraction Concr eate
25. Design Principles SOLID Design Principles were introduced
by Robert Martin in the book Agile Principles, Patterns, and
Practices in C# @2002 Code becomes more flexible and adaptable to
change, as well as more maintainable
26. Design Principles SOLID Principles Single Responsibility
Principle Open-Closed Principle Liskov Substitution Principle
Interface Segregation Principle Dependency Inversion Principle
Other Principles Dont Repeat Yourself (DRY) Separation of Concerns
(SoC)
27. Design Principles Single Responsibility Principle The
principle states that every object should only have one reason to
change and a single focus of responsibility
28. Design Principles Open-Closed Principle Open for extension,
but closed for modification Extend softwares capabilities without
changing it
29. Design PrinciplesOPC. class OPC interface Cli ent IProduct
ProductA ProductB ProductC
30. Design PrinciplesOCP.
31. Design Principles Liskov Substitution Principle The
principle dictates that you should be able to use any derived class
in place of a parent class and have it behave in the same manner
without modification.
32. Design PrinciplesLSP.
33. Design PrinciplesLSP.
34. Design Principles Interface Segregation Principle States
that clients should not be forced to depend on interfaces they dont
use. Is all about separating fat interfaces into small, specific
groups of related functionality.
35. Design PrinciplesDIP Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both
should depend on abstractions. Abstractions should not depend upon
details. Details should depend upon abstractions. => DIP Is
about isolating your classes from concrete implementations and
having them depend on abstract classes or interfaces.
37. Design PrinciplesDI Dependency Injection (DI) is a
technique that is used to allow calling code to inject the
dependencies the class needs when is instantiated 3 Primary
techniques : constructor injection, method injection, property
injection
38. Design PrinciplesDIP.
39. Design PrinciplesDIP.
40. Design PrinciplesDIP.cmp DIP IRepository IGateway Contr
oller Serv ice Gatew ay Repository IGateway IRepository IService
IService FakeGatew ay IGateway
41. cmp DIPDIP Contr oller Presentation IService. Servi ce Serv
ice IRepository IServi ce IGateway Resource Access IGateway
IRepository Gatew ay Repository
42. Design PrinciplesIoC Inversion of Control Container (IoC)
an implementation of DIP and DI responsible for object graph
instantiation initiated at application startup via code or
configuration an "assembler that makes object coupling a
run-time
43. Automotive Industry . class IoC Component1Prov iderA
Component1 Component1 Prov iderB Ca r Component2Prov iderA
Component2 Component2 Prov iderB IoC Configuration
44. Design PrinciplesIoC.
45. Design PrinciplesIoC.
46. Design PrinciplesIoC .class MVC Repository Controller Serv
ice IRepository IGateway flow IService IService Us er IRepository
Gateway IGateway
48. Design Principles Dont Repeat Yourself (DRY) Variation:
"One rule, one place Have only one place where a rule is
implemented. Separation of Concerns (SoC) Is the process of divide
your application into distinct features. Modularity A software can
be divided into separate elements called modules and that are
integrated to solve the problem.
49. Resources Wrox - Professional ASP.NET Design Patterns @2010
Wikipedia http://lostechies.com/derickbailey/2009/02/11/solid
50. Design Patterns Introduced by The Gang of Four in the book
Design Patterns: Elements of Reusable Object-Oriented Software
@1994 Reusable solution to a commonly occurring problem
52. Design Patterns GOF Design Principles Design to interfaces
Favor aggregation over inheritance Find what varies and encapsulate
it (behind an abstract class or interface) Separate use from
construction
53. Design Patterns Strategy define a family of algorithms lets
the algorithm vary independently from clients that use it Case
Study Compute primes for different insurer companies
58. Design Patterns Adapter converts the interface of a class
into another interface that the clients expect
59. Design PatternsAdapter Case Study Develop a system that
communicates with an external device Integrate a 3rd party object
that communicates with the device at the end of the project
60. Design Patterns . class Adapter class Adapter Cli ent
IGateway Cli ent IGateway + GetMeasure() : double + GetMeasure () :
void FakeGatew ay RealGatew ayAdapter + GetMeasure() : double +
GetMeasure() : double FakeGatew ay 3rdPartyObject.MeasureMethode()
RealGatew ay + GetMeasure () : void + GetMeasure () : void
3rdPartyObj ect + MeasureMetho de() : void
65. Design Patterns Bridge Separate an abstraction from its
implementation so that the two can vary independently Separate a
varying entity from a varying behavior so that the two can vary
independently
66. Design PatternsBridge Case Study Creat a system that send
notifications :email, sms Use different providers that offer
services to send sms, emails
67. Design PatternsBridge. class Bridge class Bridge class
Bridge class Bridge Notifi cation Serv iceAgentA Serv iceAgentA
Notification + +SendEmail () : : void SendEmail () void + Send() :
void Notification IServiceAgent + +SendSms() : :void SendSms() void
IServ ic eAgent +Notifi cation void Send() : + SendEmail () : void
+ SendSms() : void + Send() : void + SendEmail () : void Serv ice
AgentB Email Sms + SendSms() : void + SendEmail () : void + Serv
ice AgentB SendSms() : void Em ai l Sm s + SendEmail () : void +
Send()l : void Em ai + Sm s Send() : void + SendSms() : void Emai l
EmailAgentA : void EmailAgentB + Send() Sms SmsAgentA + Send() :
void SmsAgentB + Send() : void + Send() : void
serviceAgent.SendEmail() serviceAgent.SendSms()
72. Resources Design Patterns Explained A New Perspective on
Object-Oriented Design, 2nd Edition @2004 http://www.oodesign.com
http://www.cours.polymtl.ca/inf3700/divers/n
73. Enterprise Patterns Introduced by Martin Fowler in the book
Patterns of Enterprise Application Architecture @November 2002
74. Enterprise Patterns Layers / SoC Horizontal Separation
deployment SoC Presentation Layer Busines s Layer Resource Ac cess
Layer
75. Enterprise Patterns Presentation Layer MVP (Model View
Presenter) Model : holds the data to show on the View View :
displays the model data obtained via the presenter and delegates
user input to the presenter. Presenter : coordinates the updates
between View and Model MVC (Model View Controller) Model : holds
the data to show on the View View : displays the model data
supplied from the controller. Controller : It is the initial
contact for a request handling It interacts with the model based on
the request and selects the appropriate view to render.
76. Enterprise Patterns Service Layer Services the service
layer simply coordinates the business use case transaction and
delegates work to the business objects for all the lower-level
implementation details
77. Enterprise PatternsService Layer Messaging Patters The
Document Message simplifies the communication by encapsulating all
information within an object (DTO) The Request-Response ensures
that responses as well as requests use the Document Message pattern
Data Tranfer Objects (DTOs) An object used to transfer data between
subsystems
78. Enterprise PatternsResource Access Layer Repository
retrieve and persist your business entities typically includes CRUD
methods Query Object an object that represent a database query
79. Enterprise PatternsResource Access Layer Gateway An object
that encapsulates access to an external system or resource. Service
Agent a component acting as the front-end of communications towards
Web Services. It should be solely responsible for actions of direct
consumption of Web Services.
80. Enterprise Patterns Domain Layer Introduced by Eric Evans,
in his book Domain Driven Design Tackling Complexity in the Heart
of Software @2003
81. Enterprise PatternsModels pkg Models Doma in M odel Enti
ties ValueObj ects flow flow Relati onal Model Dimens ional Model
Fac ts Tables flow Dimensions
82. Enterprise PatternsDomain Layer Entities An object that is
not defined by its attributes, but rather by its identity Value
Objects An object that contains attributes but has no conceptual
identity
83. .Invoices Id IdContract Contracts Id Number Clients Id Name
ContractDescription Description IdIndustry IdStatus IdClient IdType
Number IdGenericContract IdGroup IssueDate IdRefContract
CorporateFunds IdType Address1 PaymentDue Address2 IdCurrency
ZipCode ExchangeRate City IdPlaceOfSupply IdCountry SubscriberName
Phone SubscriberPhone Fax aspnet_Users ApplicationId UserId
UserName LoweredUserName MobileAlias IsAnonymous
LastActivityDate
84. . .
85. Enterprise PatternsDomain Layer Aggregate groups logical
entities and value objects Aggregate Root an entity, which is the
only member of the aggregate that any object outside the aggregate
is allowed to hold a reference to
87. DDD N-Layered Architecture - Use Case : User
Authenticationpkg DDD N Layered - Use writes credentials and
Presentation Layer submits the request - Controller receives the
request View s and delegates the responsibility to Controllers
/Presenters Service - Service coordinates the use case - Step1 :
delegate AD Service Layer authentication to Repository - Step 2:
delegate logging to Serv ices Repository - Service returns that the
Use case was completed successfully - The Controller gets the
response Business/Domain Layer and decides what view to display
Enti ties - The User see the View Resource Access Layer Reposi
tories Gate w ays
88. Use Case : User Authentication .sd Class Model 1:
authenticate() 1.2: authenticate() 1.3: authenticateAD() Controller
Serv ice Gateway Actor3 flow 1.1: create() 1.4: log() View
Repository
89. Resources Wrox - Professional ASP.NET Design Patterns
@September, 2010 Patterns of Enterprise Application Architecture
@November 2002 Wikipedia
![12 Design Software Architecture - www … · 12 Design ⇒ Software Architecture Introduction to Design Readings [GJM03] Fundamentals of Software Engineering by Carlo Ghezzi, Mehdi](https://img.pdfslide.net/doc/110x75/5b5128fa7f8b9a7b648ba9f5/12-design-software-architecture-www-12-design-software-architecture-introduction.jpg)
![Software Testing Fundamentals -[1]](https://img.pdfslide.net/doc/110x75/54e77fbb4a7959397d8b492b/software-testing-fundamentals-1.jpg)
