Software design & architecture

Transcript

1. SOFTWARE DESIGN & ARCHITECTURE
2. Dmytro Dmytryshyn Android developer at Volpis 2+ years of experienceeу
3. AGENDA CONCEPT What is design & architecture 0 FLEXIBLE, REUSABLE, MAINTAINABLE More design principles 2 PRINCIPLES Four object-oriented modeling principles and how to express them using UML diagram. 1 CREDITS 3
4. 一 SOMEDEV1 //When I wrote this, only God and I understood what I was doing //Now, God only knows
5. 一 SOMEDEV2 // I am not sure if we need this, but too scared to delete.
6. SOFTWARE DESIGNER Responsible for outlining a software solution to a specific problem by designing the details of individual components and their responsibilities
7. SOFTWARE ARCHITECT Responsible for looking at the entire system and choosing appropriate frameworks, data storage, solutions and determining how components interact with each other
8. Software architecture looks at the higher level aspects of a system Software design looks at the lower level aspects of a system
9. So, how to start implementing awesome design?
10. Just do it? coding
12. So, how to?
13. STEPS TO AWESOME DESIGN REQUIREMENTS 0 TECHNICAL DIAGRAMS 2 CONCEPTUAL MOCKUPS 1 CODING 3
14. TYPES OF REQUIREMENTS 0 1 2 BUSINESS USER SOFTWARE
15. TYPES OF REQUIREMENTS 0 1 2 BUSINESS USER SOFTWARE Express the purpose for which the product is created
16. TYPES OF REQUIREMENTS 0 1 2 BUSINESS USER SOFTWARE Description of tasks that the user can perform using the system Express the purpose for which the product is created
17. TYPES OF REQUIREMENTS 0 1 2 BUSINESS USER SOFTWARE Description of tasks that the user can perform using the system Express the purpose for which the product is created • Functional - describe what should and should NOT be done by the system • Non-functional - describe the properties of the system when implementing its behavior
18. CONCEPTUAL MOCKUPS
19. CRC Cards (Class Responsibility Collaborators) Responsibilities Class Name Responsibilities Collaborators
20. Responsibilities Meetup - Provide date - Provide location - Provide list of participants - Add participant - Remove participant - Participants
21. Responsibilities Meetup - Provide list of participants - Add participant - Remove participant - Location - Participants - Date Responsibilities Location - Provide address - Overall capacity Date - Provide localized date - Meetup - Meetup
22. UML DIAGRAM Is a diagram based on the UML (Unified Modeling Language) with the purpose of visually representing a system along with its main actors, roles, actions, artifacts or classes, in order to better understand, alter, maintain, or document information about the system
23. TYPES OF UML DIAGRAM 0 STRUCTURAL • Class • Package • Object • Component • Composite structure • Deployment 1 BEHAVIORAL • Activity • Sequence • Use case • State • Communication • Interaction overview • Timing
24. PRINCIPLES OF OBJECT-ORIENTED DESIGN ABSTRACTION 0 DECOMPOSITION 2 ENCAPSULATION 1 GENERALIZATION 3
25. ABSTRACTION Abstraction is the idea of simplifying a concept in the problem domain to its essentials within some context. Abstraction allows you to better understand a concept by breaking it down into a simplified description that ignores unimportant details
26. Meetup title: String location: Location date: Date isFree(): Boolean
27. ENCAPSULATION
28. ENCAPSULATION Hiding inside details
29. ENCAPSULATION Hiding inside details Packing data and functions that modify that data into a single component and restricts access to certain inside details
30. PROS OF ENCAPSULATION Combines data and functions in one place 0 Helps with software changes 2 Secure sensitive information 1
31. Meetup - title: String - location: Location - date: Date - participants: List<Participant> + isFree(): Boolean + getParticipants(): List<Participants> + addParticiapnt(participant: Participant): Unit Access modifiers: public + internal ~ private - protected #
32. DECOMPOSITION It is the division of a large object into smaller parts, or on the other hand, the grouping of smaller objects with different functionality into one larger one. Decomposition makes it possible to break a big problem into smaller ones that are easier to understand and solve.
33. Responsibilities Meetup - Provide list of participants - Add participant - Remove participant - Location - Participants - Date Responsibilities Location - Provide address - Overall capacity Date - Provide localized date - Meetup - Meetup
34. TYPES OF RELATIONSHIPS IN DECOMPOSITION • Association - is “some” relationship, this means that there is a loose relationship between two objects. These objects may interact with each other for some time. • Aggregation - is weak “has-a” relationship, this means is although parts can belong to the holes, they can also exist independently. • Composition - is strong “has-a” relationship, This means is that the whole cannot exist without its parts.
35. Meetup - title: String - location: Location - date: Date - participants: List<Participant> + isFree(): Boolean + getParticipants(): List<Participants> + addlParticiapnt(participant: Participant): Unit Participant - id: Int - role: Role + getId(): Int + getRole(): Role 0..* Relationships in UML diagram: Association - Aggregation - Composition -
36. Meetup - title: String - location: Location - date: Date - participants: List<Participant> + isFree(): Boolean + getParticipants(): List<Participants> + addParticiapnt(participant: Participant): Unit Participant - id: Int - role: Role + getId(): Int + getRole(): Role 0..* - address: String - capacity: Int - meetups: List<Meetup> 0..* 0..* Location Date Role <<enumeration>> Speaker Visitor Organizer
37. GENERALIZATION Helps us to reduce the amount of redundancy when solving problems
38. Meetup - title: String - location: Location - date: Date - participants: List<Participant> + isFree(): Boolean + getParticipants(): List<Participants> + addParticiapnt(participant: Participant): Unit KLUGMeetup <<interface>> ICancelableMeetup + cancelMeetup() + cancelMeetup()
39. open class Pizza constructor( val size: Int ) { private val toppings: MutableList<String> init { toppings = ArrayList() } fun addToppings(toppings: List<String>){ this.toppings.addAll(toppings) } } class PepperoniPizza(size: Int) : Pizza(size){ init { addToppings(listOf("Pepperoni")) } }
40. open class Animal constructor( val numberOfLegs: Int, val hasTail: Boolean ) { open fun walk() { Log.d("Animal", "walk") } open fun run() { Log.d("Animal", "run") } } class Dog : Animal(4, true) class Whale : Animal( 0, true) { override fun walk() { swim() } override fun run() { swim() } private fun swim() { Log.d("Whale", "swim") } }
41. MORE PRINCIPLES TO MAKE YOUR CODE SHINE COUPLING AND COHESION 0 CONCEPTUAL INTEGRITY 2 SEPARATION OF CONCERNS 1
42. COUPLING Focuses on the description of the interconnections between modules, and how much one module knows about the other and how closely they are connected
43. COHESION Represents the clarity of the responsibilities of a module
44. + get(flag: Int): Int Sensor fun get(flag: Int) = when (flag) { 0 -> this.temperature 1 -> this.brightness else -> throw IllegalArgumentException( "Unknown flag") }
45. + get(): Int ISensor << interface >> + get(): Int BrightnessSensor + get(): Int TemperatureSensor
46. SEPARATION OF CONCERNS Design principle for separating a computer program into distinct sections, so that each section addresses a separate concern
47. SmartPhone - camera: Byte - phone: Byte + takePhoto() + savePhoto() + enableFlash() + makeCall() + encrypyOutgoingCall()
48. SmartPhone - camera: ICamera - phone: IPhone + takePhoto() + makeCall() ICamera + takePhoto() + savePhoto() + enableFlash() << interface >> IPhone + makeCall() + encrypyOutgoingCall() << interface >>
49. CONCEPTUAL INTEGRITY It’s about creating consistent software. It's making decisions about how your system will be designed and implemented, so that even if multiple people worked on the software, it would seem as if there was only one mind guiding all the work
50. Have any question? Speak now or forever hold your peace
51. Searching for a great, quality-oriented team? Fill yourself like an ambitious junior android software engineer? Write to us, maybe we searching for dev like you!
52. CREDITS • https://www.coursera.org/learn/object-oriented-design? • https://medium.com/@a.yevtukhov/требования-requirement s-часть-2-cb747d201907 • https://medium.com/@manjuladube/encapsulation-abstractio n-35999b0a3911 • https://ru.wikipedia.org/wiki/Инкапсуляция_(программиро вание) • https://en.wikipedia.org/wiki/Separation_of_concerns • https://studfiles.net/preview/6488866/page:6/