From Problem to Solution

 Problem Statement:
 Select a Particular S/W Development Methodology(Agile, UP, Waterfall, DevOps etc.) according to the nature of the problem/project.
 Start System Analysis
 Start SDLC with in selected methodology of above step.
 Develop Use Cases models
 Domain Modeling: Specify entities of the problem
 Draw SSD (System Sequence Diagram) of each Use Case
 Start Design
 Specify High Level Design using Logical Architecture/ Architectural Pattern(package diagrams*)
 Draw / Specify System Architecture or Physical Architecture (Deployment Diagram*)
 Start Low Level Design (Perform static and dynamic designing in parallel) Imp: Select and apply Design Patterns wherever needed.
 Static Design
 Class Diagrams/ Class Relationship Diagrams()
 Package Diagrams
 Deployment Diagrams
 Dynamic Design
 Interaction Diagrams(Object Sequence Diagrams and Communication/Collaboration Diagrams)
 Activity Diagram
 State Machine Diagrams
Design Concepts
 Abstraction
 Architecture
 Patterns
 Separation of Concerns
 Modularity
 Information Hiding
 Functional Independence
 Refinement
 Aspect
 Refactoring
Design Principles
 Principle 1. Design should be traceable to the requirements model
 Principle 2. Always consider the architecture of the system to be built
 Principle 3. Design of data is as important as design of processing functions
 Principle 4. Interfaces (both internal and external) must be designed with care
 Principle 5. User interface design should be tuned to the needs of the end user. However, in every case, it should stress
ease of use
 Principle 6. Component-level design should be functionally independent.
The functionality that is delivered by a component should be cohesive—that is, it should focus on one and
only one function or subfunction.
 Principle 7. Components should be loosely coupled to one another and to the external environment.
 Principle 8. Design representations (models) should be easily understandable.
 Principle 9. The design should be developed iteratively. With each iteration, the designer should strive for greater
simplicity
Design Process
 Start with the high level design(logical) of the system by specifying architectural
pattern that is appropriate for the software
 Design subsystems(functionaly cohesive)
 Design Subsystem Interfaces
 allocate these subsystems within the architecture
 Design the classes or components
 Design the methods and messages of each class
 Evaluate and select design patterns for a design class or a subsystem
 Design any interface required with external systems or devices
 Design the user interface
 Develop a deployment model(Physical Design)
Agile software engineering

 Agile software engineering combines a philosophy and a set of development

guidelines. The philosophy encourages customer satisfaction and early
incremental delivery of software; small, highly motivated project teams;informal
methods; minimal software engineering work products; and overall development
simplicity. The development guidelines stress delivery over analysis and design
(although these activities are not discouraged), and active and continuous
communication between developers and customers.
Agile Manifesto
 Agile places more importance on
 Individuals and interactions over process and tools
 Workingsoftware over comprehensive
documentation
 Customer collaboration over contract negotiation
 Responding to changes over following a plan
The 12 Principles of Agile Development
 The following agile principles are what define an approach as agile.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for
the shorter timescale.
4. Businesspeople and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust
them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation
The 12 Principles of Agile Development
 The following agile principles are what define an approach as agile.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
Extreme Programming

 What is XP?
 Most widely used approach to agile software development
 An Agile Framework
 XP-Foundation
 Five Values establishes a foundation of XP
 Communication
 Simplicity
 Feedback
 Courage
 respect
XP-Values

 Communication
In order to achieve effective communication between software engineers and other
stakeholders (e.g., to establish required features and functions for the software), XP
emphasizes close, yet informal (verbal) collaboration between customers and developers,
the establishment of effective metaphors for communicating important concepts,
continuous feedback, and the avoidance of voluminous documentation as a communication
medium.
In the XP context, a metaphor is “a story that everyone—customers, programmers, and
managers— can tell about how the system works”
XP-Values

 Simplicity
To achieve simplicity, XP restricts developers to design only for immediate needs, rather
than consider future needs. The intent is to create a simple design that can be easily
implemented in code).
XP-Values

 Respect
XP-Values

 Feedback
Feedback is derived from three sources: the implemented software itself, the customer, and
other software team members. By designing and implementing an effective testing
strategy, the software (via test results) provides the agile team with feedback. XP makes
use of the unit test as its primary testing tactic. As each class is developed, the team
develops a unit test to exercise each operation according to its specified functionality. As
an increment is delivered to a customer, the user stories or use cases that are implemented
by the increment are used as a basis for acceptance tests. The degree to which the software
implements the output, function, and behavior of the use case is a form of feedback.
Finally, as new requirements are derived as part of iterative planning, the team provides
the customer with rapid feedback regarding cost and schedule impact.
XP-Values

 Courage
In a complex system such as a software development team, it's easy for fear to arise : fear
that we will be blamed for an action we took, or that we will break some functionality and
the build; fear that we will look as incompetent; fear that our product won't be
successful.However, in XP no one fear anything because no one ever works alone. So XP
gives a courage to all because all are responsible and due to simplicity, feedback and
communication a courage is build in every member.
Module VS Component
 A Physical manifestation of module is called a component [Ref].
 Developers physically package modules in different ways, sometimes depending
on their development platform. We call physical packaging of module a
component. Most languages support physical packaging as well: jar files in Java,
dll in .NET, gem in Ruby, and so on. We can say, package is a component jar file
is a component. Dll file is a component set of routines in a dll file is a component.
S/W Architecture Style
Data Centric Architecture
Data Flow Architecture
Call & Return Architecture
Layered Architecture
Architectural Issue: Model-View Separation

 The model(domain) objects should not have a direct knowledge of views(UI)

objects. E.g. Register or Sale objects should not send directly a message to a GUI
window object (ProcessSaleFrame e.g)
Motivations of Model-View Separation
Architectural Patterns

 Reusable solutions to the general architectural problems

 During the design of architecture, sometimes a specific problem within a
particular context with specified constraints arises that can be solved by using a
defined solution and that architectural solution is called A.P. Hence, an A.P is a
solution to specific architectural problem. MVC, for instance, solves the problem
of separating the UI from the model. S.C.A (Sensor-Controller-Actuator), is a
pattern that will help you with the problem of actuating in face of several input
senses. An Architectural Style, on the other hand, is just a name given to a
recurrent architectural design. Contrary to a pattern, it doesn't exist to "solve" a
problem. Pipe&filter doesn't solve any specific problem, it's just a way of
organizing your code. Also, a single architecture can contain several architectural
styles, and each architectural style can make use of several architectural patterns
MVC Architectural Pattern
 https://www.youtube.com/watch?v=mtZdybMV4Bw
 It is a pattern to organize and modularize the code to improve
maintainability/understandability/modularity.
Advantages of MVC Architecture
 MVC architecture offers a lot of advantages for a programmer when
developing applications, which include:
• Multiple developers can work with the three layers (Model, View, and
Controller) simultaneously
• Offers improved scalability, that supplements the ability of the application
to grow
• As components have a low dependency on each other, they are easy to
maintain
• A model can be reused by multiple views which provides reusability of
code
• Adoption of MVC makes an application more expressive and easier to
understand
• Extending and testing of the application becomes easy
Important Point.

 These architectural styles are only a small subset of those available. Once
requirements engineering uncovers the characteristics and constraints of the
system to be built, the architectural style and/or combination of patterns that best
fits those characteristics and constraints can be chosen. In many cases, more than
one pattern might be appropriate and alternative architectural styles can be
designed and evaluated. For example, a layered style (appropriate for most
systems) can be combined with a data-centered architecture in many database
applications.