Programming in the large
Download as PPTX, PDF1 like257 views
The document discusses two types of programming: 'programming in the small,' which focuses on creating small, easily manageable programs, and 'programming in the large,' which deals with complex systems involving multiple modules and developers. Key principles of software evolution, complexity, and best practices in software design, such as responsibility-driven design and clean architecture, are highlighted. Additionally, it emphasizes the importance of models in reasoning and problem-solving in programming.
![struct Stack {
int top;
unsigned capacity;
int* array;
};
void push(struct Stack* stack, int item)
{
if (isFull(stack))
return;
stack->array[++stack->top] = item;
}
int pop(struct Stack* stack)
{
if (isEmpty(stack))
return INT_MIN;
return stack->array[stack->top--];
}](https://image.slidesharecdn.com/programminginlarge-190711124022/85/Programming-in-the-large-41-320.jpg)
![class Stack {
private int top;
private int a[] =
public boolean push(int x)
{
}
public int pop()
{
}](https://image.slidesharecdn.com/programminginlarge-190711124022/85/Programming-in-the-large-42-320.jpg)
Programming in the large
- 1. Programming in the large Naveen Muguda
- 2. Two kinds of medicines • Over the counter • Prescription
- 4. programming in small • activity of writing a small program. • Small programs are typified by being small in terms of their source code size, • are easy to specify, quick to code and typically perform one task or a few very closely related tasks very well.
- 5. • Programming in the large • by larger groups of people or by smaller groups over longer time periods • program changes can become difficult • If a change operates across module boundaries, the work of many people may need re-doing.
- 6. Laws of Software Evolution • An E-program is written to perform some real-world activity; • how it should behave is strongly linked to the environment in which it runs, • needs to adapt to varying requirements and circumstances in that environment
- 7. Laws of Software Evolution • "Continuing Change" —must be continually adapted or it becomes progressively less satisfactory. • "Increasing Complexity" —its complexity increases unless work is done to maintain or reduce it. • "Conservation of Organisational Stability (invariant work rate)" — the average effective global activity rate in an evolving system is invariant over the product's lifetime. • "Continuing Growth" — the functional content of a system must be continually increased to maintain user satisfaction over its lifetime. • "Declining Quality" — the quality of a system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes.
- 9. Price of being reactive
- 13. • Complexity reflects the number and nature of entities that comprise the software, and the number and nature of interactions between them.
- 16. Complex • a complex issue is one in which you can’t get a firm handle on the parts and there are no rules, algorithms, or natural laws. • "Things that are complex have no such degree of order, control, or predictability" • A complex thing is much more challenging--and different--than the sum of its parts, because its parts can interact in unpredictable ways.
- 18. Complicated • "the components can be separated and dealt with in a systematic and logical way that relies on a set of rules or algorithms.” • allows you to deal with it in a repeatable manner.
- 19. Size | Nature Simple Complex Complicated small ✓ large ✓ ✓
- 20. complicated • order, control, predictability • rules, algorithms, laws, recipes
- 21. Complicatedness • “Liberties constrain, constraints liberate”
- 23. goal of programming in the large • Make system “complicated” instead of being complex
- 24. complexity • Inherent needs to be managed • Accidental needs to be reduced/eliminated
- 25. perspective • programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.” - Peter Naur
- 26. perspective • programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.” -Peter Naur
- 27. Problem solving • apply the model • create/change/delete the model
- 28. When you drive • apply the model • create/change/delete the model
- 29. Programming in the large • apply the model • create/change/delete the model
- 32. Models allow us to deal with new situations • They expedite reasoning
- 33. • “seems like pub-sub system” • “looks like a bounded buffer” • “it’s going to be master slave system”
- 34. Model • General idea behind many specific ones • People remember abstractions
- 36. That vs How • 5 * 6 => knowing that • 47 * 78 => knowing how
- 37. • knowing that doesn’t scale • knowing how scales • People remember methods/mechanisms
- 38. • “will use a builder” • “will wrap that in a optional” • “will use a circuit breaker”
- 39. • Theories “compress” knowledge.
- 40. • int relationshipStatus • Enum RelationShipStatus { Single, Married, Divorced}
- 41. struct Stack { int top; unsigned capacity; int* array; }; void push(struct Stack* stack, int item) { if (isFull(stack)) return; stack->array[++stack->top] = item; } int pop(struct Stack* stack) { if (isEmpty(stack)) return INT_MIN; return stack->array[stack->top--]; }
- 42. class Stack { private int top; private int a[] = public boolean push(int x) { } public int pop() { }
- 44. • Anti pattern: Primitive obsession, Procedural Programming, Beans
- 45. Bad practice • Anemic Domain Model • “ domain model where the domain objects contain little or no business logic (validations, calculations, business rules etc.)”
- 46. • 39865 / 17
- 49. • composability
- 50. • On the criteria to be used in decomposing systems into modules David L Parnas, 1971 • “that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart”
- 51. “axis of change” • “We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. • Each module is then designed to hide such a decision from the others”
- 52. • Bad practice: controller based decomposition
- 53. Categories of models Domain Solution RDD Design patterns Architecture Styles Coding Styles Math, Logic Logic Set Theory Discrete Maths Category Theory Infrastructure Concurrency Model, Process model Database, Event Queue, Data Structures Distributed Systems
- 54. • Models should be filtered, precise, compressed and organized perceptions of knowledge.
- 56. Inspiration of models • Theory | Story | Observation| Math | Metaphor
- 57. CRC • Model for reasoning about objects/classes • Identify a class’s • responsibilities • collaborations
- 58. Responsibility Driven Design • objects play specific roles and occupy well-known positions. • community of objects. • Each object is accountable for a specific portion of the work. • Objects collaborate in clearly-defined ways.
- 59. Responsibility Driven Design • object(class)’s role determines its responsibility
- 61. Control styles • Centralized control style • Delegated control style • Clustered control style • Dispersed control style • Preferred control style
- 62. RDD: #1 :MVCRDD #1
- 63. MVC • Model: manages the data, logic and rules of the application. • View: output representation of information • Controller: accepts input and converts it to commands for the model or view
- 64. RDD: #2 EBI • How to design the model • Entity : Represent the business objects and contain business logic • Boundary: model the interface with the system • Interactor: Use case
- 67. • The outer circles are mechanisms. The inner circles are policies. • The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle.
- 68. • Independent of Frameworks. • Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element. • Independent of UI. • Independent of Database. Your business rules are not bound to the database. • Independent of any external agency.
- 69. Domain Driven Design • Entity • Value object • Domain Event • Service • Factory • Repository
- 71. complex
- 72. complicated
- 73. Bounded Context
- 78. Patterns
- 79. Architectural Styles Structure Component-based Monolithic application Layered Pipes and filters Shared memory Database-centric Blackboard Rule-based Messaging Event-driven aka implicit invocation Publish-subscribe Asynchronous messaging Adaptive systems Plug-ins Microkernel Reflection Domain specific languages Distributed systems Client-server (2-tier, 3-tier, n-tier exhibit this style) Shared nothing architecture Space-based architecture Object request broker Peer-to-peer Representational state transfer (REST) Service-oriented Cloud computing patterns