Upload
trend-micro
View
97
Download
0
Tags:
Embed Size (px)
Citation preview
OutlineWhat is software architecture?
Designing software architectures
Communicating architecture
Agile software architecture
Workshop
As juniors, pull together something new.As seniors, practice new solutions and architectures.
As operations, create a deeper understanding and define a common language with our engineers.
This is for us devops team.
Software architecture is basically the structure of your code. How you define the variables to be used and how you group
them in to classes in such a way that your code will be readable to any audience or programmer.
Common Conceptions
It is the overall design of the System or Product we are developing. This does not only include the System Design, meaning the form of the code of the product, but also all the tools and the processes that
will help complete the product or system.
Common Conceptions
Software ArchitectureAs a noun:
Structure, interaction of components, foundations, infrastructure, solutions, eagle’s eye view
Software ArchitectureAs a verb:
Creating a vision and making design decisions
Requirements drive architecture
Software architecture, besides code
https://leanpub.com/software-architecture-for-developers/read
Logging and exception handling
Security; non-repudiation, integrity
SLO
Audit and other regulatory
requirements.
Sociability with other software systems.
Operational requirements
Consistency of structure
VISION
Design choices
The software architect is a leader.
Leads by building consensus, particularly in the form of competing design requirements. It is up to the architect to make good solid
judgement calls.
Kartik Ayyar’s answer in Quora.com
Software Architecture as DesignFUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS
EXPLORING THE DESIGN SPACE
Big Ball of Mud“… is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle…
These systems show unmistakable signs of unregulated growth, and repeated, expedient repair…
The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition.”
http://www.laputan.org/mud/
Requirements Engineering
Process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
Examples of RequirementsUser requirements:
The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.
System requirements:
On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated.
The system shall automatically generate the report for printing after 17.30 on the last working day of the month.
A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs.
If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit.
Access to all cost reports shall be restricted to authorized users listed on a management access control list
Types of Requirements
FUNCTIONAL REQUIREMENTS
Describe what the system is supposed to do
“Features”, as succinct as a user story, or as specific as a SBI
The system shall do … [give clean/detected, give category, give source]
NON-FUNCTIONAL REQUIREMENTS
Describe what the system is supposed to be
“Qualities” of a system, ex. guarantees SLA of 99.999%, open-source, usable
The system shall be … [99.999% SLA, scalable, releasing monthly]
Performance and Space RequirementsCAN BE SPECIFIED AT THE O-NOTATION (HIGHLY DETAILED)
CAN BE SPECIFIED VIA SLO AND GIGABYTES REQUIRED (JUST RIGHT)
And my personal favorite… Agility
Anticipating future improvements, mitigating risk, creating a feedback loop
But more on that later.
Exploring the design space
The space of possible designs. This is a good design exercise for the team!
Sample exploration
Parallel Messaging
Series Messaging
Distributed Database
Data in Message
MongoDB
MySQL Cluster
Other NoSQL DB
Pipe and FiltersLittle components “decorating” the output one at a time
Swap components and none will be the wiser
http://www.site.uottawa.ca/school/research/lloseng/
MicroservicesDivide into “small”, reliable interfaces and mash together to produce interesting results
“Fail easy, fail fast”
Understanding design is communicating design.
Focus on the communication of the solution rather than the solution itself
“Sadly, we as an industry has a failure to communicate.” –Simon Brown
Who uses UML?Sketches are good enough, right? Right?
Due to the nature of our team, we don’t actually need to visualize the design to other people. Hence no need for UML.
Although I agree that UML is useful for designing, I think prototyping is a faster design tool.
Moving fast needs fast communication.
(next slides from Simon Brown’s Software Architecture for Developers)
Good sketches facilitate good discussions.
TitlesShort and meaningful
LinesClear relationships, color coded or
has notes if necessary
LayoutYou can use sticky notes instead.
ColorAdd in legends if needed.
DescriptionAdd in a short description if the
component is sufficiently complex.
CohesionThings that are alike should be seen together, like databases.
C4 DiagramsIt’s typically difficult to show everything in one go.
Overview first, zoom in.
Diagrams are to help the audience navigate.
A software system is made up of containerseach of which contains one or more componentswhich in turn are implemented by one or more classes.
ContainersWhat are the high level tech decisions?
How do the containers communicate with each other?
Where do the different workgroups work on?
Agility? Moving fast, embracing change, releasing often, getting feedback.
Unfortunately, not all agile teams build software that is agile.
Observation – Orientation – Decision – Action LoopFaster than the adversary.
http://www.dnipogo.org/fcs/pdf/adolph_2006_agile%20lessons_final.pdf
Good architecture enables agility.
“Base your architecture on requirements, travel light and prove your architecture with concrete experiments.”
- Scott Ambler
Travelling Light – Just enoughTOO LITTLE
No common understanding where the system boundaries are.
Inability to do the elevator pitch.
No thoughts on the non-functional requirements.
No thoughts on the risks involved.
TOO MUCH
Unnecessary detail in long documents
Writing code or pseudo-code.
No flexibility with the design choices.
Analysis paralysis.
Just Enough Architecture
Firm Foundations
StructureUnderstand the different
elements and their relationships based on the requirements.
------------Team discussions
VisionCreate and communicate the
“big picture”-----------------
C4 Diagrams, Use Case diagrams, Entity Diagrams
RisksIdentify and mitigate the biggest
risks.---------------
Risk-storming, documentation and experimentation
RiskConsequences of actions taken in the face of uncertainty.
Time and human resource constraints
Technology choice
Process workflow
Customer satisfaction A risk is a known problem beforehand. Risks should have mitigation plans. If you ignore risks, more likely you’ll encounter lots of problems.
Architecture is not a relay sport.
Architecture evolves.
Somebody should own it, and change it as uncertainties are cleared.
Do experiments and live feedback throughout the project lifetime.
Technical leadership and coaching is needed on all stages of the project.
Architectural Kata30-45 minutes of planning, 10 minutes of presentation
Prove to the others your solution works
Any tech, can make assumptions, no all-star team
Constructive criticisms only!
I am the sales guy
DeliverablesHigh level description and architecture – the elevator pitch
Non-functional requirements and their solutions
Use Case Diagrams and their respective 4C Diagrams (until the components only)◦ (Include the technology choices!)
Soft PBI timelines – dates of feature deliveries
GRID Food NetworkA Philippine restaurant food chain wants to enable orders through the Internet.
Users: millions+, 99.999% SLA (~8 hours, 45 minutes of downtime a year)
Requirements:
Users will place their order, then be given a time to pick up their order and directions to the shop which must integrate with Google Maps;
If the shop offers a delivery service, dispatch the driver with the order to the user;
Mobile-device accessibility;
Occasionally offer national promotionals/specials through Facebook, Twitter and Zomato API;
Daily offers of local promotionals/specials with Foursquare.
Accept payment online or in person/on delivery
Integrate with the company’s customer relationship management (loyalty cards) by sending it all customer data with their orders
Integrate with the company’s supply chain management system by sending it all orders from all branches
ReferencesSoftware Architecture for Developers - https://leanpub.com/software-architecture-for-developers/read
Lecture slides accompanying the book: Object-Oriented Software Engineering: Practical Software Development using UML and Java http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/LlosengCh09E2.ppt
Assorted slides from CS 260, Advanced Software Engineering, in UP Diliman
Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.