Upload
olafur-andri-ragnarsson
View
70
Download
0
Embed Size (px)
DESCRIPTION
Hönnun hugbúnaðar er sjaldan þannig að maður getur valið hvað sem maður vill. Oftar en ekki höfum við ekki aðeins kröfur um hvað forritið á að gera, heldur einnig hvernig það gerir það. Má nefna gæðakröfur, hraða, skalanleika og allskyns non-functional kröfur. Einnig geta verið kröfur um tungumál og aðllögun að ólíkum löndum. Erfitt getur verið að fá þessar kröfur upp úr þeim sem eru að óska eftir hugbúnaðnum séum við að skrifa hann fyrir aðra. Hugbúnaður hefur einnig takmarkanir eins og hvaða tækni má nota, hvaða staðla og annað sem þegar er ákveðið. Þar fyrir utan eru takmarkanir sem stafa af þróunarteymum og fleirl. Í þessum fyrirlestri ætlum við að líta á þá þætti sem þarf að huga að þegar verið er að hanna hugbúnað og ætti að negla niður áður en farið er að útfæra.
Citation preview
Lecture 08Architecture Considerations
Agenda Goals Architecture Drivers Non-functional Requirements Constraints Principles
Reading Brown: III Designing software– Chapters 21-25 (both included)
Goals of an Enterprise Architecture Be robust Be performing and scalable Take advantage of OO design principles Avoid unnecessary complexity Be maintainable and extensible Be easy to test Promote reuse
Requirement Considerations Goals based on business requirements– Support for multiple client types– Portability
Support for multiple client types– Does we need to support different client types?– Do we need abstraction layer?
Portability– Does the application need to be independent of
a particular middleware, like databases?– Do we need abstraction layer?
ARCHITECTUREDRIVERS
Architectural Drivers Functional Requirements Quality Attributes Constraints Principles
Architectural Drivers We must understand these drivers at a
high-level– Creativity can come from constraints
Clear VISION– Architecture is about STRUCTURE and VISION– Must be communicated
Will help in the decision process– When faced with a decision, the vision will tell
you
Quality Attributes Requirements are easy to understand– People can (mostly) explain the features they
want It’s the non-functional requirements that
are more tricky– The “ilites”
Performance Performance is about how fast something
is– This must always be a consideration
Applies on multiple levels:– Hardware specification– Network setup and security– Architecture of the software– The programming of the software– Protocols used– Middleware and containers
Performance Response Time is the amount of time for
the system to process a request from the outside
server processing…client request
network
response
The user waits until the transactionis done
Performance Responsiveness is how quickly the
system acknowledges a request as opposed to processing it
server processing…client request
network
responsewaiting…
The user sees that the system isdoing something
Performance Latency is the minimum time required to
get any form of response, even if the work to be done is nonexistent
nothing…client request
network
response
The overhead of the request andnetwork transfer
Performance Throughput is how much stuff you can
do in a given amount of time
t1 t2time
records processed…
Performance Load is a statement of how much stress a
system is under
Performance Load sensitivity is an expression of how
the response time varies with the load
Performance Efficiency is a performance divided by
resources Capacity of a system is an indication of
maximum effective load
Scalability The measure of how adding a resource
affects the performance– Vertical: Make the hardware faster, more
memory etc– Horizontal: Get more hardware – scaling out
How many concurrent transaction can the system handle– Request per second or per minute
Availability The degree to which your software is
operational– Measured in terms of “nines”– 99.99% per year - four nines, uptime in terms
of percent Usually specified in Service Level
Agreements (SLA) 99.99% is downtime:– Daily: 8.6s– Weekly: 1m 0.5s– Monthly: 4m 23.0s– Yearly: 52m 35.7s
Security Overall all security issues are vital– Authentication and authorization– Hardware access restrictions on network levels– Firewalls– Open Web Application Security Project
(OWASP)– Security Roles for people– Securing sensitive information, for example
encrypting data
Disaster Recovery Response to failures– Disk crash, faulty network card etc– Network downtime
External disaster – force major– Fires, earthquake
Business Continuity Plan– Specifies how a business can recover from
disasters
Monitoring Infrastructure to track activities in the
system– Hardware capacity, such as disk space,
memory, CPU load– System transactions
Monitoring software– SNMP standard– Viewing tools
Auditing Traceability of what happens in the system– Logging of events– Software to track changes
Some software must allow for external auditing– All transactions are logged– All changes to record data is logged– Any event can be viewed
Software Requirements Flexibility– The ability for non-technical people to modify
business rules within the system Extensibility– The ability to extend and modify software for
new needs Maintainability– Think about the cost of running software over
some time
Other Requirements Legal, regulatory and compliance– Laws that regulate industries
Internationalization (i18n)– What languages must be supported
Localization (L10n)– Does the software need to be adapted to local
cultures
NON-FUNCTIONALREQUIREMENTS
Non-Functional Requirements The challenge is to capture the non-
functional requirement Instead of asking how much availability (-
ability) ask specific questions– “How much downtime can you tolerate?”– “How many users are there max?”– “How much do you expect to sell?”
Non-Functional Requirements Categorize non-functional requirements– Sometimes the best solution is really not what
is needed– Sometimes features are not required to begin
with Use MoSCoW– Must, Should, Could, Wont
CONSTRANTS
Constraints Time and budget constraints– There is always a deadline
Technology constraints– Approved technology – Technology Stack
Existing System and Interoperability– Middleware or standards used
Target Deployment Platform– Must run in Windows or Linux
Constraints Technology Maturity– Established middleware or bleeding edge
Open Source– Use of proprietary software or open source
Vendor Relationship– Firms make partnerships with technical
vendors Past Failures– We tried this technology and it did not work
and we don’t want it
Constraints Internal Intellectual Property– Developed in house and must be used
Corporate Policies– Reports, memos, approvals
Consultants– Have all the answers, of course
People Constraints People set constrains– Size of Teams – Two Pizza Teams are common– Skillset and combination of skills– Hiring and training of new employee –
scalability – Who can work with whom – social status
problems
Organization Constraints Politics– Obstacles, people protecting their turf
Strategic software or tactical– Affect priority and resource allocations
Communications paths– Conway’s Law
Access to support– Are you important enough?
Risk Management All projects have risks– Track risk by two metrics: likelihood (0-100)
and impact (0-5)– Highest risk is the highest likelihood x impact– For each have a mitigation plan, i.e. explain
how you react if risk becomes reality Risks examples– External vendor does not deliver, hardware is
not there on time, development problems, politics, bugs
Practical Considerations Solutions are designed and implemented
according to time schedule and budget– Hardest part is management of people
Practical Considerations Risk is in feature creep and things out of
control
PRINCIPLES
Principles Guidelines for how to work– Keeps development effort uniform
Development Principles– Coding standards– Automated unit tests– Static analytic tools– Build strategy– Deployment strategy
Principles Architecture Principles– Layering– Business Logic– Statelessness– High Cohesion, Low Coupling or SOLID– Persistence strategy– Domain model– HTTP protocols– Consistency strategy
Summary Goals– High-level vision for the architecture
Architecture Drivers– Quality, Performance, scalability, etc.
Non-functional Requirements– Capturing
Constraints– We always have to work within some boundary
Principles