Architecture Definition

• A “software architecture” is the structure (or

structures) of a system,
which comprise ( contain)
– software components ,
– the externally visible properties of those
components , App

– and the relationships among them .

Logic Generic
GUI

Win32

02 - Architecture Intro. CSC407 1

 Components & Structures
• Architecture defines “components”
– an abstraction
– Suppresses / (deep) details not important to its
interactions with other components
• An architecture comprises (contain) more than
one structure
• modular structure (calls / uses)
• process structure (invokes , communicates with,
synchronises)
• physical structure (libraries, DLL’s, processors)
• inheritance structures (inherits)

02 - Architecture Intro. CSC407 2

 In Practice

• \Divide into two levels:

– System-Level Architecture
– Programming-Level Design

User Interface
– Sometimes also referred to as “design” (or even
“architecture”)

02 - Architecture Intro. CSC407 3

 Design & Architecture in the Development Process

Requirements

Architecture

Design Design Design Design

Code C&ut C&ut C&ut C&ut C&ut C&ut

&
Unit
Test
Integration Test

System Test

02 - Architecture Intro. CSC407 4

 Software Architecture
• Specifying at the highest level the construction of
the system:
– Technology choices
• Platforms, language, database, middleware, …
– System construction
• Overall pattern: Monolithic ( harmony ), RDBMS,
client/server, 3-tiered, n-tiered, distributed, …
• Hardware interfaces (if any)
– Division into programs
– E.g. a program for data entry, another for data analysis, a Web-
oriented interface, …
– Division of programs into major subsystems
• Reuse strategy (shared subsystems)
• Calls constraints
• Major strategies
02 - Architecture Intro. CSC407 5
 Software Design
• We are now considering how to lay down code.
• E.g., Object-Oriented
– What classes? What inheritance amongst the classes?
– What classes will call , what other classes ?
– How are classes grouped into subsystems (e.g. Java
packages)?
– What data members of classes
• Must decide these things at some point during the
coding process.
– Wish to minimize re-writes now and down the line
– Danger in early over-complexity ( Extreme
Programming) or rabid

02 - Architecture Intro. CSC407 6

 Architecture & Design
• Architecture
– High-level
– Major ( main) decisions
– Not even thinking about programming
• Design
– “Laying out” or planning the programming
language code used to implement the
architecture
– Organizing programming language concepts
But, …. no standard terminology
02 - Architecture Intro. CSC407 7
 Documentation of an Architecture
• Golden Rule of Software Development:
– If it’s not reviewable (written down), it doesn’t exist.

• Architectures sometime suffer from over-elaborate

(detailed ) documentation
– Unnecessary. Simply document your decisions.
– Most systems don’t deserve ( need ) elaborate architectural
documentation
• Dealing with unknowns
– Indicate they are unknown for the present (attendee ) .
– Cycle back later and add new decisions taken
– But beware of costs of postponing (delay ) decisions

• Must keep architecture document up-to-date

– Very hard to do in practice: takes effort
– Therefore keep it simple as possible (but no simpler)

02 - Architecture Intro. CSC407 8

 How do we describe an architecture?
Control
Process
(CP)

Prop Loss Reverb Noise

Model Model Model
(MODP) (MODR) (MODN)

• What is the nature of the components?

• What is the nature of the links?
• Does the layout have any significance?
• How does it operate at runtime Must Be Clear!
– Dataflow
– Control flow
• Can we evaluate this architecture?
02 - Architecture Intro. CSC407 9
 Two Main Architectural Structures
• Modular / part structure
– Purely static
– Disappears at run-time
• Structures that survive (created) through
execution
– E.g., pipes, processes, networks, objects, …
• Both views need to be considered (not the
same)

02 - Architecture Intro. CSC407 10

 The Essence ( core ) of the Architecture
Document
• Imagine after the system has been built try to
describe a form as possible how the system has been
put together.
• Be completely clear
• you only have an hour in which to do it.
• your target audience is knowledgeable professionals
in the field, but unfamiliar with the domain.
• They will wish to evaluate your choices

02 - Architecture Intro. CSC407 11

 Documentation of a Design
• UML (Unified Modeling Language)
– Expresses OO design using diagrammatic notation
– Complete UML for a typical system is very large.
– A selection must be made for presentation
• Choose the most illuminating parts
• Simplify w.r.t. the actual code
• Divide into small sections (< 1 page)
• Add written text to describe the whys and wherefores.
• Danger of UML and code getting out of synch over time
– Automated tools to keep the two in-synch
• E.g., Rational Rose
– Problem with these tools:
• Not literate (read –write )
• Don’t work as well as we would want, cumbersome to use (tired )
• detail is difficult, simplifying (lying) is difficult
• Selection of parts for presentation is primitive
• try to explain (in writing) your choices to another programmer
02 - Architecture Intro. CSC407 12
 Documentation
• Architecture
– Informal diagrams
– Written explanations
– Bullet points
• Design
– Formal UML
– Reflects and in-synch with program structure
– Simplify and divide into small chunks / parts
for presentation
– Add written explanations.
02 - Architecture Intro. CSC407 13
 The Waterfall Model
• Requirements → Architecture → Design →
Code → Test
– Variations: Spiral, prototyping, …
• All will have architecture and design artefacts
• Dave Parnas: “A Rational Design Process: How
and when to fake it”
– Not important that the steps are followed in this order
– Only important that after the fact, there are documents
that make it appear as though the process was followed
in that order.

02 - Architecture Intro. CSC407 14

 Documentation In Practice
• As much requirements as you can manage without getting
bogged (got ) down.
• As much architecture as you can manage without getting
bogged down
• Some design
• Some code
• More design
• More code
• Make architecture
• Fix and repair requirements
• …

02 - Architecture Intro. CSC407 15

 Why is architecture important?
• Manifests early design decision
– most difficult to get correct and hardest to change
– defines constraints on the implementation
– inhibits or enables quality attributes
• Defines a work-breakdown structure
– organization (especially important for long-distance development)
– estimation
• A vehicle for stakeholder communication
– an architecture is the earliest artefact that enables the priorities among
competing concerns to be analysed
• Reviewable
– architectural errors are vastly and more expensive to fix once a system has
been coded
– Can serve as a basis for training new developers
– As an indication of progress
02 - Architecture Intro. CSC407 16
 Why is design important?
• When dealing with ~100s of packages and ~1000s of
classes, coders lose sight of the forest for the trees.
– Leads to designs that are muddled and inconsistent
• Buggy, requiring constant re-work
• Long learning curve for new developers
• Hard to fix bugs
– Long time to debug, lots of code to fix, introduce new bugs
• Hard to change
– Lots of time to figure out how to change, lots of code to change,
introduce lots of new bugs
• Higher-level design descriptions lead to better designs
– Can grasp (understand the design at its essence and in its entirety
– Can review and correct early
• Can be used to leverage the skills and experience of better
designers across many developers

02 - Architecture Intro. CSC407 17

 Where does architecture come from?
Developing Customers
organization
Marketing
End Users

Current technical previous experience

environment
Architect

02 - Architecture Intro. CSC407 18

 What does architecture affect?
– The structure of the developing organisation
– The enterprise goals of the developing organisation
– customer requirements for the next system
– influence later architectural decisions

02 - Architecture Intro. CSC407 19

 Architecture process steps

• create the business case

• understand the requirements
• create the architecture
• represent and communicate the architecture
• evaluate the architecture
• implement based on the architecture
– ensuring conformance
• enhance/maintain based on the architecture
– ensuring conformance

02 - Architecture Intro. CSC407 20

 Functionality & Quality Attributes
• Functionality usually takes 1st place during
development.
• Systems are more frequently re-designed not
because they are functionally deficient, but rather
because
– They are difficult to maintain
– Difficult to port
– Won’t scale
– Too slow
– Too insecure
– Not fault tolerant

02 - Architecture Intro. CSC407 21

 System Qualities
• Observable (note ) via execution
– Performance
– Security
– Availability
• Reliability = mttf = mean time to failure
• Availability = mttf/(mttf + time to repair)
– Functionality
– Usability
• Not observable via execution
– Modifiability
– Portability
– Reusability
– Integrability
– Testability

02 - Architecture Intro. CSC407 22

 Business Qualities

– Time-to-market
– Cost
– Projected lifetime
– Target market
– Use of legacy systems

02 - Architecture Intro. CSC407 23

 Architectural Qualities

• Conceptual integrity
• Correctness
• Completeness
• Buildability
– Completed by available team in a timely
manner

02 - Architecture Intro. CSC407 24

 Architectural Means of Achieving Quality
• Two questions
– What structure shall I employ to
• Assign workers
• Derive a work breakdown
• Exploit pre-packaged components
• Plan for modification
– What structure shall I employ so that the
system, at runtime, fulfills (accomplish) its
behavioral and quality attributes.

02 - Architecture Intro. CSC407 25

 ‫• معمارية البرمجيات ( )‪Software Architecture‬هي مجموعة من القرارات‬
‫األساسية المتعلقة بهيكلية نظام برمجي‪ ،‬وكيفية تقسيمه إلى مكونات مختلفة‪ ،‬وتحديد العالقات‬
‫بين هذه المكونات‪ ،‬وأسلوب االتصال بينها‪ .‬تعتبر معمارية البرمجيات العنصر األساسي في‬
‫بناء أنظمة برمجية ناجحة وقابلة للصيانة‪ ،‬حيث تسهم في تحديد الهيكل األساسي للنظام الذي‬
‫سيؤثر على أدائه‪ ،‬قابليته للتوسع‪ ،‬وسهولة صيانته‪.‬‬
‫• العناصر األساسية لمعمارية البرمجيات‪:‬‬
‫• المكونات ( ‪Components):‬هي الوحدات األساسية التي تشكل النظام‪ ،‬مثل الوحدات‬
‫البرمجية أو الخدمات‪ .‬يمكن أن تشمل هذه المكونات وحدات برمجية‪ ،‬خدمات ميكروية‪ ،‬أو‬
‫مكتبات‪.‬‬
‫• المكونات من خالل أحداث تُرسل عبر النظام‪.‬‬
‫• أدوات تصميم معمارية البرمجيات‪:‬‬
‫• ‪UML (Unified Modeling Language):‬لغة نموذجية تستخدم لتصميم المعمارية‬
‫عن طريق رسم المخططات‪.‬‬
‫• ‪Enterprise Architect:‬أداة لتمثيل وتصميم المعمارية للمشاريع الكبيرة‪.‬‬
‫• ‪C4 Model:‬طريقة لتوثيق معمارية البرمجيات باستخدام أربع مستويات من المخططات‪.‬‬
‫حيث‪02‬‬ ‫‪Intro.‬ام عليها‪،‬‬
‫‪- Architecture‬‬ ‫التحتية األساسية التي يتم بناء النظ‬
‫•‪ 26‬باختصار‪ ،‬معمارية البرمجيات هي البنية‪CSC407‬‬
‫يجب أن تكون مدروسة بعناية لتلبية المتطلبات الحالية والمستقبلية للنظام‪.‬‬
‫العالقات بين المكونات‪ :‬تحدد كيف تتفاعل هذه المكونات مع بعضها البعض‪ .‬يمكن أن يكون‬ ‫•‬
‫ذلك من خالل واجهات برمجية ()‪ ،APIs‬قنوات اتصال‪ ،‬أو أنواع أخرى من التفاعل مثل‬
‫االتصال عبر الرسائل‪.‬‬
‫األنماط المعمارية ( ‪Architectural Patterns):‬هي نماذج جاهزة تُستخدم لحل‬ ‫•‬
‫مشكالت شائعة في تصميم البرمجيات‪ .‬من أشهر األنماط‪:‬‬
‫– ‪MVC (Model-View-Controller):‬فصل منطق األعمال عن واجهة المستخدم‪.‬‬
‫– ‪Microservices:‬تقسيم النظام إلى خدمات صغيرة ومستقلة يمكن تطويرها وتشغيلها بشكل‬
‫منفصل‪.‬‬
‫– ‪Layered Architecture:‬تقسيم النظام إلى طبقات مثل طبقة البيانات‪ ،‬طبقة األعمال‪،‬‬
‫وطبقة العرض‪.‬‬
‫القرارات غير الوظيفية ( ‪Non-functional Requirements):‬وتشمل هذه القرارات‬ ‫•‬
‫األداء‪ ،‬األمان‪ ،‬القابلية للتوسع‪ ،‬االعتمادية‪ ،‬وقابلية الصيانة‪ .‬تُعد هذه األمور مهمة لضمان‬
‫نجاح النظام على المدى الطويل‪.‬‬
‫التقنيات واألدوات‪ :‬تحدد التكنولوجيا واألدوات المستخدمة لتطوير النظام مثل لغات‬ ‫•‬
‫البرمجة‪ ،‬قواعد البيانات‪ ،‬وأطر العمل (‪Frameworks).‬‬
‫أهمية معمارية البرمجيات‪:‬هذا النمط على استجابة النظام لألحداث التي تحدث‪ ،‬حيث يتم‬ ‫•‬
‫‪02 - Architecture Intro.‬‬ ‫‪CSC407‬‬ ‫التواصل بين‬ ‫‪27‬‬
‫•‬ ‫قابلية التوسع‪ :‬المعمارية الجيدة تسهل توسيع النظام مع زيادة المتطلبات أو‬
‫المستخدمين‪.‬‬
‫•‬ ‫المرونة‪ :‬يتيح التصميم المرن إجراء تغييرات في المستقبل دون الحاجة إلى‬
‫إعادة بناء النظام من الصفر‪.‬‬
‫•‬ ‫األداء‪ :‬يسهم التخطيط الجيد للمعمارية في تحسين أداء النظام من خالل‬
‫تحديد كيفية توزيع العمل بين المكونات‪.‬‬
‫•‬ ‫الصيانة‪ :‬النظام الذي تم تصميمه بشكل جيد يكون أسهل في الصيانة‬
‫وإصالح األخطاء‪.‬‬
‫•‬ ‫التعاون بين الفرق‪ :‬من خالل تقسيم النظام إلى مكونات واضحة المعالم‪،‬‬
‫يصبح من السهل على الفرق المختلفة العمل بالتوازي‪.‬‬

‫‪02 - Architecture Intro.‬‬ ‫‪CSC407‬‬ ‫‪28‬‬

 ‫األنماط المعمارية الشائعة‬

‫( ‪Monolithic Architecture‬المعمارية األحادية)‪ :‬النظام يكون كتلة‬ ‫•‬

‫واحدة‪ ،‬حيث يتم بناء جميع المكونات في نفس التطبيق‪ .‬هذه المعمارية قد‬
‫تكون بسيطة لكنها تصعب التوسع مع مرور الوقت‪.‬‬
‫( ‪Micro services Architecture‬المعمارية القائمة على الخدمات‬ ‫•‬
‫الصغيرة)‪ :‬تقسيم النظام إلى خدمات صغيرة يمكن تطويرها بشكل مستقل‪،‬‬
‫مما يتيح مزيدا ً من المرونة في التطوير والصيانة‪.‬‬
‫‪Service-Oriented Architecture (SOA):‬يشبه إلى حد ما‬ ‫•‬
‫المعمارية القائمة على الخدمات الصغيرة‪ ،‬ولكنه يركز على توفير الخدمات‬
‫عبر واجهات موحدة‪.‬‬
‫( ‪Event-Driven Architecture‬المعمارية الموجهة باألحداث)‪ :‬يعتمد‬ ‫•‬

‫‪02 - Architecture Intro.‬‬ ‫‪CSC407‬‬ ‫‪29‬‬