Download to read offline
![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)
![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/75/Programming-in-the-large-41-2048.jpg)
![class Stack {
private int top;
private int a[] =
public boolean push(int x)
{
}
public int pop()
{
}](https://image.slidesharecdn.com/programminginlarge-190711124022/75/Programming-in-the-large-42-2048.jpg)
Uploaded byNaveenkumar Muguda
Programming in the large
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.
More Related Content
Similar to Programming in the large
Programming in the large
- 1. Programming in thelarge Naveen Muguda
- 2. Two kinds ofmedicines • 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 inthe 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 SoftwareEvolution • 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 SoftwareEvolution • "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 beingreactive
- 12.
- 13. • Complexity reflectsthe number and nature of entities that comprise the software, and the number and nature of interactions between them.
- 16. Complex • a complexissue 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 componentscan 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 | NatureSimple Complex Complicated small ✓ large ✓ ✓
- 20. complicated • order, control,predictability • rules, algorithms, laws, recipes
- 21. Complicatedness • “Liberties constrain,constraints liberate”
- 23. goal of programmingin the large • Make system “complicated” instead of being complex
- 24. complexity • Inherent needsto be managed • Accidental needs to be reduced/eliminated
- 25. perspective • programming properlyshould 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 properlyshould 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 • applythe model • create/change/delete the model
- 28. When you drive •apply the model • create/change/delete the model
- 29. Programming in thelarge • apply the model • create/change/delete the model
- 32. Models allow usto deal with new situations • They expedite reasoning
- 33. • “seems likepub-sub system” • “looks like a bounded buffer” • “it’s going to be master slave system”
- 34. Model • General ideabehind many specific ones • People remember abstractions
- 35.
- 36. That vs How •5 * 6 => knowing that • 47 * 78 => knowing how
- 37. • knowing thatdoesn’t scale • knowing how scales • People remember methods/mechanisms
- 38. • “will usea 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 { inttop; 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 { privateint top; private int a[] = public boolean push(int x) { } public int pop() { }
- 44. • Anti pattern:Primitive obsession, Procedural Programming, Beans
- 45. Bad practice • AnemicDomain Model • “ domain model where the domain objects contain little or no business logic (validations, calculations, business rules etc.)”
- 46.
- 49.
- 50. • On thecriteria 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 DomainSolution 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 shouldbe filtered, precise, compressed and organized perceptions of knowledge.
- 56. Inspiration of models •Theory | Story | Observation| Math | Metaphor
- 57. CRC • Model forreasoning 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
- 60.
- 61. Control styles • Centralizedcontrol style • Delegated control style • Clustered control style • Dispersed control style • Preferred control style
- 62.
- 63. MVC • Model: managesthe 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
- 66.
- 67. • The outercircles 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 ofFrameworks. • 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
- 70.
- 71.
- 72.
- 73.
- 77.
- 78.
- 79. Architectural Styles Structure Component-based Monolithic application Layered Pipesand 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