ُsoftware Architecture

صفحه 1:
Software Architecture OL. Week 

صفحه 2:
Outline sic Ovwer ‏سا‎ Giles oo oooo 

صفحه 3:
Basic Concept he ‏موه و ی موه وه ماه‎ Prawework trot desorbes ts Por oad structure — ‏سا اجه وه طا‎ they Pa ‏و‎ © bad archierturd desta Por o bukdery ‏تسج چا مس‎ by «pod ‏موه ۳ موی‎ is tre Por soPware kere oe siles oF buikdtory cod soPivane architecture 

صفحه 4:
Architectural design process ‎sinwtuiey‏ سره لا ‎2 0١5 ‏مرو‎ i ‏ور موه و لوط‎ sb-systews aed ope ‏ممه تمس سملت محا مجميججا ووصادصم‎ khestP ad ‎DF Coeiral wodettery ‎© worl oP the oouiel rekticoships between he dPPereul pats PP thre yeasty te reatabbesrd ‎DQ 00‏ وططدم من اودرو مدص جمد ‎De KdeciPied sub-spstews‏ < 

صفحه 5:
Sub-systems and modules ها موه ‎mwa rh Whose‏ چا ۱ ورد و و محصحطد © لا وراه واه ‎by‏ موس موه بط اه ماو ‎to oer‏ وه طم با مرو و وج طلوت و لا ‎cowpeas bul would wot weedy be cowkered wo separde‏ ‎ann ‎ 

صفحه 6:
Architectural models 2 ‏اه رصق‎ oad weodtkr decowpostion way be based ooo pari dkar wedel or archiecturd sive ‎Ahowever, wost systews ore hetervyeurvus in thot dPPRereut ports of‏ لا ‎he systew oe bee oo dPPeredt woe oad, it sowe oes, he‏ اج موه و ‎syste wey Polow‏ ‎Qo Dke orchtecturd wodel used oPRevis ‏دجوا جات ,عم ووم جما‎ Ustrbutcbliy oad cvaictcicabity oP he systew 

صفحه 7:
System structuring ز ز ز ز ز [ ز ز 000 151250 Phe arhierturd ‏ذا مادص‎ corwdly expressed oy o bok dagraw preseutog oc Dver view oP ihe Syste since Qore speckic odes showin how sub-sysiews share chs, ore ‏لاوس‎ ond talerPare wih euck ker way dso be devebped 

صفحه 8:
Architectural Style 

صفحه 9:
1. Main Program With Subroutines M fan-out a 7 6 ‏و‎ ‎depth ‎0 e k 1 7 1 ‏اا ؟‎ 7 o|le q fan-in i i r ‏جع‎ width) ———__________» 

صفحه 10:
Control ge icc, Output rted output 10 Sort Shift Procedure call store shifts input Input + —-Access to data structure + 0 

صفحه 11:
2. Abstract Data Type 11 Control Input Store Shift output 

صفحه 12:
سوق لا :وکام ۶ ‎PuCkor(rw,0,):‏ » | ite caled oPer ol apuioes have bera stored troy successive ols of (PuChar() > Linen (): delivers the onober of hoes stores < Worde(r) > Chers(rw) * Cher(rw.7) ‏سب لا‎ < 001 ‏سس سس‎ > Read Pro tpt od call PuCher(...) < 0 ‏اسان‎ 12 

صفحه 13:
13 حورت لا (اسسا۵) ۶ ()عل۵۳0) < (سبااس ۵۳0 < ‎OP Cher (|w,2)‏ » وه لا موقم < ‎xpetlortex(w)‏ * 

صفحه 14:
Output output 3. Implicit Invocation ۷ Sort Control Shift 1 MakeShift Store ۳ call The MakeShift module is no explicitly called 14 Input فيح كريد | input سر 

صفحه 15:
4. Pipe and Filter Input Shift Sort Output input output 15 

صفحه 16:
5. Repository 0 8 ‏ما عه سس سق‎ data. Dhis wep be dour is tu ways! > Oka datas held 0.0 ceurd dotcbuse or repostiory vad way be aovessed by ul sub-ppsiews * Cok b-systew wotdate is nwo dotobose od posses cota explo) io vier sub-syotews ‎cxpounis of dota ore to be shored, the reposiiory cde‏ وا ما لا لح رات ات سا ‎DP shartay‏ ‎16 

صفحه 17:
17 واه ‎software‏ client software Conti. olient olient software software Data store (repository or back board) client client sofware software client software client software 

صفحه 18:
Conti. OD ‏سمل‎ ‎PR Rpeot way to share barge axons oF ett © Oxb-systews werd wt be coaerced wit how data is prokuced ۶ ‏وب موم تون‎ backup, smu), et. © Garay wodel is published os the repository schewa دعست لا 6 ‏روم و وه وه امه و روول‎ data wodel. Teevitabhy ‏وه و‎ © Octo evoked is dP Pod cod expecive 18 

صفحه 19:
6. Layered ‘components user interhoe layer application layer utlity layer 19 

صفحه 20:
7. Client-server Opttbuied syste corde whick shows how cota ced processions i ‏ص و ار رح و مه اما‎ ‎servers whick provide speniic services sucks‏ ی ‎pricier, dota (KREME, FIP.‏ ‎Get oP chects whick cull va hese services ‎Qetwork which dows ches to aoess servers ‏ند ۴ ‎20 ‎oo ۲ o 

صفحه 21:
Conti. 2 ‏مه‎ ‎© Oisinbuion oP cha ts straghPorward © Oches ePPertve use oP uetuorked syste » Cray ok wew servers or upgrade exten servers ‏منم لا‎ » Op shard dot wodel sv ‏له سس وله‎ dota Dep. © Dot interchouge way be toePPiciect © Op cedird reyeter of canes oad services - i way be hard ‏و‎ ‎Rid out whol servers ond services ore avcthibke 21 

صفحه 22:
Control Model 

صفحه 23:
Control models OQ Ore coerced wih he poukol Pow betowen sub-spotews. < Opi Brow the systew deoownpontion woe امه سین تا وه له امه ۳ راو اوه وا وولو و ۶ اه لمیر تا اه ای رام و موه مه ‎Cork ab-sysiew‏ 2 اوه ‎sysiew's‏ با و موجه مهام مس 23 

صفحه 24:
1. Centralized control مج ‎takes respousbliy Por wane he‏ وولو امه 8 ۵ موجه ان جر ‎Cohretwn wodel‏ تا ‎ Dop-dowa subroutce wodel‏ < ‎starts of he ip oP a subroutce hierarchy ond woves‏ اون ‎cbunward.‏ ‏سوه وی نا ‎ Opplouble‏ < امن موق ۲ ‎Owe systew vxwppuedl ood the sippy, start) ocd‏ < ‎vihur syoiay prouvon.‏ ات ومشكعل ممم ‏.75 جاجبره م۱ ‎24 

صفحه 25:
Call-return model 25 

صفحه 26:
A centralized control model for a real-time system control 

صفحه 27:
2. Event-driven systems OQ Orvea by extercaly yruerced suede where te tan of ‏ها و‎ puide the coal of the sub-spstews whick process he evel نامك صه و اه وت اه تس ‎Na‏ 2 من و ماود مین سا سا زرا لوط او موه ام مس تا ۶ ‏بطم ۵ موه 0 لو لو‎ 7 dl ab-spstews. gy abaystew whick oom ‏مد صل بوب مرو بطم‎ * Agerpedived odes. Osed i nedhioe sysiews where ‏مه مه با لد بو مر‎ kouder oad passed ‏ها‎ ‏مس ما موه ی و‎ 27 

صفحه 28:
Broadcast model و و وه حول مه موه هفخ سس ‎Oke these‏ وه ود و مد و يي معيو ‎ihe sub-syotew whick vee bode the‏ و اما امه سوه ار ‎Cowl poly is wt ewbedded in the eve ood wessape kooder. Gub-spstews decide va eves oP toterest io hew ‏الم بت رب مره مج لت تن ام موجه ,جوا ‏وت ات ‎m1.registerTo(m2)‏ ‎m2 receive an event m2 will call m1 ‎ ‎28 

صفحه 29:
Broadcasting pay ۱ 6 ‏مر‎ 3 system (Subsystem) ۲ ‏ر‎ ۱ 4 J ‘Event and message hander 29 

صفحه 30:
Interrupt-driven systems عا هو مه ها وص ممصم ‎sysiews where Pot‏ لین ‎Osed in‏ ‎resid‏ here ore ku we tlerrupt ype wie a hoader dePced Por euck bpe و له مها پر ه عاتن له چا بو ‎ack‏ ‎trePer tp ts harder‏ ی[ Olbws Post respowe bu pwplex ty proyreny ood dPPiodl ‏لطس جا‎ 30 o oo oOo 

صفحه 31:
31 “Process ۲ ~ Process » “ Process ١ / Prowss > JY SQ SQ ‏لفت‎ Handler Handler Handler 3 4 Handler vector Interupt Intermupts Interrupt-driven control 

صفحه 32:
32 Modular Decomposition 

صفحه 33:
The problem that they have to deal with are complex, ..., software engineers cannot reduce this complexity. However, it can be funneled and confined within weakly coupled closed areas. By judicious segmentation of the 33 

صفحه 34:
Modular decomposition ات او و مره موم وه اوه ططلو وتو ون من 2 Oa cbt wodel where he syetew ‏صم لوطل ذا‎ irom, ‏جاعزنا‎ 2 © detePw sodel where the systew ts devowposed into ‏جنه نا ود موم نطو مخ‎ Pls ‏ات او او من‎ 4P possble, devia chow comme shod be dekyed ‏لس‎ لجوج اتوص ‎ser‏ امي 34 

صفحه 35:
Object models ‎systew hig a set oF lovey coupled ober wih welt‏ با ص66 ‎wit Rect ray object‏ اه موس ‎Objectoneded‏ ‏هه واه و ای ال ای ‎Ow: ‎> pose) pow led: the ‏اه ماو‎ objects oa be coded ‏مويك لفن‎ vier objevts ‎< Cosly wodeled: obects are oPea represrataions oP rector retires ‎33 ‏م ۲ ۲ ۲ 

صفحه 36:
Invoice processing system 36 

صفحه 37:
Data-flow models (Cusetcod trresPorwalives process their taputs to produce ‏یی‎ ‎Quy be rePerred to os 3 pipe ord Pier coded (cr ict DD IX shell) و فصو ان موی بو ‎oP this approach ore‏ نو ‎sequedid, this iso back sequectdl wodel whick ip exteosively used ia dott‏ ‎sysiews‏ ] Oot edly exible Por ‏وه عم‎ Ow. سجن مس با و A eka ‏روت تن‎ peop ‏فا اه هوجو وا اه‎ ood 0۲ 7۲ ۶ Bunlviey the ‏تن بل با مود‎ tnnePorwdios & uly ‏اسرد‎ معاصيره أمامصوجد د عن لسمصجموه د جد اه ماو ‎to‏ و وا ۶ 37 ooo oo 

صفحه 38:
Invoice processing system ‎Isue ۱‏ / تحت ثم ار ‎Le pe‏ ‎ ‎38 

صفحه 39:
Domain-Specific Architecture 

صفحه 40:
Domain-specific architectures QO rchiectird codes whisk ore speoPic b soe ‏و موب‎ QD woe pes oP ‏ات مود‎ » Cevere wok whick ore obsiewives Prow a anober oP red pyeteave axl whieh eoruakiy ‏لمم جما‎ vhuruterttee oP hove opti °° Duy be rewed dreviy ino desi °° ‏ال موی‎ ۶ ‏الب حون مج(‎ oe wore cbyirw, Medked woe. Crovdle ‏اجه موه ره موی ما مه موه اه مت و‎ UP ‏متاخ پمج مومت‎ ۱ popare possibe: architerture © Dop-dows woe 40 

صفحه 41:
Generic models Crxopler wade io weltkanwa expe dha oher wodets exist ‎dooce‏ ماو اوه سوت و واه لیا 2 ‎ Gycobol ible‏ < سمل سر < ‏عصا 6 2 رل صطممموی ‏ < ی ولو < ‎0 ‎1 ‎41 

صفحه 42:
A data-flow model of a compiler Synbol tdle © Lexical ١ © Syntactic ١ (Semantic ١ coe ( _ amlyss > amlyss > amlysis Pr generdion ) 42 

صفحه 43:
The repository model of a language processing system 

صفحه 44:
Reference architectures RePerewe woteb oe derived Prow ‏صا خا تلم م‎ upphcuica ‏وه وه و ما مود‎ Quy be wed «5 beste Por ‏مه مود‎ or 0 ‏موه‎ ‎UPPereot syotews. Wore or 0 stoked ‏موی‎ whic ‏مه وود‎ be evoked ره موه بو اون لوا هب للم 661 44 

صفحه 45:
45 OSI reference model متام نارجه ‎Presentation‏ ‎Session‏ ‎Transport‏ ‎Network‏ ‎Data link‏ ‎Physal‏ Network Datalink Physal Communications medium Presentation Session, Transport Network Datalink Physial 

صفحه 46:
Design Pattern 

صفحه 47:
۱ OO00 ‘OO0’00 

صفحه 48:
48 What is a Pattern? QO Current use comes from the work of the architect Christopher Alexander O Alexander studied ways to improve the process of designing buildings and urban areas Q “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem anda solution.” Q Hence, the common definition of a pattern: “A solution to a problem in a context.” Q Patterns can be applied to many different areas of human endeavor, including software development 

صفحه 49:
Why Pattern? Q "Designing object-oriented software is hard and designing reusable object-oriented software is even harder." - Erich Gamma QO Experienced designers reuse solutions that have worked in the past Q Well-structured object-oriented systems have recurring patterns of classes and objects QO Knowledge of the patterns that have worked in the past allows a designer to be more productive and the resulting designs to be more flexible and reusable 49 

صفحه 50:
OQ 1987 - Cunningham and Beck used Alexander’s ideas to develop a small pattern language for Smalltalk Q 1990 - The Gang of Four (Gamma, Helm, Johnson and Vlissides) begin work compiling a catalog of design patterns Q1991 - Bruce Anderson gives first Patterns Workshop at OOPSLA ‎Kent Beck and Grady Booch sponsor the first‏ - 1993 لا ‎meeting of what is now known as the Hillside Group‏ ‎QO 1994 - First Pattern Languages of Programs (PLoP) conference ‎01995 - The Gang of Four (GoF) publish the Design Patterns book ‎50 

صفحه 51:
Types of software patterns Q Organizational O Analysis QO Design O Process Q Project Planning QO Configuration Management 53 

صفحه 52:
Types of software patterns O Riehle and Zullighoven in “Understanding and Using Patterns in Software Development” mention three types of software patterns Q Conceptual Pattern » Pattern whose form is described by means of terms and concepts from the application domain QO Design Pattern » Pattern whose form is described by means of software design constructs, such as objects, classes, inheritance and aggregation Q Programming Pattern (Programming Idiom) » Pattern whose form is described by means of programming language constructs 52 

صفحه 53:
Design Pattern Le Abstraction QO Complex design for an entire application or subsystem ۳ abstract Q Solution to a general design problem in a More concrete particular context J QO Simple reusable design class such as a linked list, hash table, etc. 53 

صفحه 54:
GoF Design Patterns QO The GoF design patterns are in the middle of these levels of abstraction QA design pattern names, abstracts, and identifies key aspects of a common design structure that makes it useful for creating a reusable object-oriented design.” QO The GoF design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” 54 

صفحه 55:
GoF Classification Of Design Patterns Q Purpose - what a pattern does ~ Creational Patterns * Concern the process of object creation ~ Structural Patterns * Deal with the composition of classes and objects » Behavioral Patterns * Deal with the interaction of classes and objects Q Scope - what the pattern applies to ~ Class Patterns * Focus on the relationships between classes and their subclasses * Involve inheritance reuse > Object Patterns * Focus on the relationships between objects * Involve composition reuse 55 

صفحه 56:
GoF Essential Elements Of Design Patterns Q Pattern Name » Having a concise, meaningful name for a pattern improves communication among developers O Problem + What is the problem and context where we would use this pattern? ~ What are the conditions that must be met before this pattern should be used? Q Solution » A description of the elements that make up the design pattern » Emphasizes their relationships, responsibilities and collaborations > Not a concrete design or implementation; rather an abstract description O Consequences > The pros and cons of using the pattern > Includes impacts on reusability, portability, extensibility 56 

صفحه 57:
GoF Pattern Template Q Structure > A graphical representation of the pattern Q Participants > The classes and objects participating in the pattern QO Collaborations » How to do the participants interact to carry out their responsibilities? QO Consequences » What are the pros and cons of using the pattern? QO Implementation » Hints and techniques for implementing the pattern 57 

صفحه 58:
GoF Pattern Template Q Pattern Name and Classification » A good, concise name for the pattern and the pattern's type O Intent » Short statement about what the pattern does Q Also Known As » Other names for the pattern Q Motivation » A scenario that illustrates where the pattern would be useful Q Applicability » Situations where the pattern can be used 58 

صفحه 59:
GoF Pattern Template OQ Sample Code > Code fragments for a sample implementation QO Known Uses > Examples of the pattern in real systems O Related Patterns > Other patterns that are closely related to the pattern 59 

صفحه 60:
Key points | ip respousble Por derivieny 9 strurtirdd systew ‏له او او و رال‎ a mbes ears ‏ممصم مسحي‎ coated (pars ‏ی رو و و موم‎ chest ‏تا ماوت تس له بات نو‎ ال مهو لو اوه هه ماود ‎Control wodels‏ 60 

صفحه 61:
Key points Oodular devowposiiva wodels tachide doto-Flouy ocd object wodets ‎over a‏ و بو ‎wes‏ ماه ود وتا ‎epplcdicn dowar. They way be cowsiructed by obsiractay Pro‏ اه جوا ال بو رو و موه ‎pena‏ ‎61 

صفحه 62:
The architectural model provides a Gestalt view of a system, allowing the software engineering to examine it as a whole R. Pressman 62 

Software Engineering Software Architecture N.L. Hsueh N.L. Hsueh, SE-Lab IECS FCU 1 Software Engineering Outline  Basic Concept  Architecture Styles     Control models Modular decomposition Domain-specific architectures Design Pattern N.L. Hsueh, SE-Lab IECS FCU 2 Software Engineering Basic Concept  The architecture of a system is a comprehensive framework that describes its form and structure – its components and how they fit together  A bad architectural design for a building cannot be rescued by good construction; the same is true for software  There are styles of building and software architecture N.L. Hsueh, SE-Lab IECS FCU 3 Software Engineering Architectural design process  System structuring  The system is decomposed into several principal sub-systems and communications between these sub-systems are identified  Control modelling  A model of the control relationships between the different parts of the system is established  Modular decomposition  The identified sub-systems are decomposed into modules N.L. Hsueh, SE-Lab IECS FCU 4 Software Engineering Sub-systems and modules  A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.  A module is a system component that provides services to other components but would not normally be considered as a separate system N.L. Hsueh, SE-Lab IECS FCU 5 Software Engineering Architectural models  Structure, control and modular decomposition may be based on a particular model or architectural style  However, most systems are heterogeneous in that different parts of the system are based on different models and, in some cases, the system may follow a composite model  The architectural model used affects the performance, robustness, distributability and maintainability of the system N.L. Hsueh, SE-Lab IECS FCU 6 Software Engineering System structuring  Concerned with decomposing the system into interacting sub-systems  The architectural design is normally expressed as a block diagram presenting an overview of the system structure  More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed N.L. Hsueh, SE-Lab IECS FCU 7 Software Engineering Architectural Style N.L. Hsueh, SE-Lab IECS FCU 8 Software Engineering 1. Main Program With Subroutines N.L. Hsueh, SE-Lab IECS FCU 9 Software Engineering Control Input Shift store Sort shifts Output sorted input Procedure call output Access to data structure i/o N.L. Hsueh, SE-Lab IECS FCU 10 Software Engineering 2. Abstract Data Type Control Input Store output N.L. Hsueh, SE-Lab IECS FCU Output Shift Sort output 11 Software Engineering  Store    initialStore: PutChar(r,w,c,d): CloseStore: it is called after all inputlines have been stored through successive calls of PutChar() Lines(): delivers the number of lines stores  Words(r)  Chars(r,w)  Char(r,w,c)  Input  Call Store.initialStore()  Read from input and call PutChar(…)  Call CloseStore()  N.L. Hsueh, SE-Lab IECS FCU 12 Software Engineering  Shift ShiftLines()  ShiftWords(l)  ShiftChars(l,w)  ShiftChar(l,w,c)  Sort  iniSort  getIndex(w)  N.L. Hsueh, SE-Lab IECS FCU 13 Software Engineering 3. Implicit Invocation Control Input input MakeShift Store Sort Shift Output output Implicit call The MakeShift module is no explicitly called N.L. Hsueh, SE-Lab IECS FCU 14 Software Engineering 4. Pipe and Filter Input input N.L. Hsueh, SE-Lab IECS FCU Shift Sort Output output 15 Software Engineering 5. Repository  Sub-systems must exchange data. This may be done in two ways:  Shared data is held in a central database or repository and may be accessed by all sub-systems  Each sub-system maintains its own database and passes data explicitly to other sub-systems  When large amounts of data are to be shared, the repository model of sharing is most commonly used N.L. Hsueh, SE-Lab IECS FCU 16 Software Engineering Conti. N.L. Hsueh, SE-Lab IECS FCU 17 Software Engineering Conti.  Advantages  Efficient way to share large amounts of data  Sub-systems need not be concerned with how data is produced  Centralized management e.g. backup, security, etc.  Sharing model is published as the repository schema  Disadvantages  Sub-systems must agree on a repository data model. Inevitably a compromise  Data evolution is difficult and expensive N.L. Hsueh, SE-Lab IECS FCU 18 Software Engineering 6. Layered N.L. Hsueh, SE-Lab IECS FCU 19 Software Engineering 7. Client-server  Distributed system model which shows how data and processing is distributed across a range of components  Set of stand-alone servers which provide specific services such as printing, data management, etc.  Set of clients which call on these services  Network which allows clients to access servers N.L. Hsueh, SE-Lab IECS FCU 20 Software Engineering Conti.  Advantages  Distribution of data is straightforward  Makes effective use of networked systems  Easy to add new servers or upgrade existing servers  Disadvantages  No shared data model so sub-systems use different data organization.  Data interchange may be inefficient  No central register of names and services - it may be hard to find out what servers and services are available N.L. Hsueh, SE-Lab IECS FCU 21 Software Engineering Control Model N.L. Hsueh, SE-Lab IECS FCU 22 Software Engineering Control models  Are concerned with the control flow between sub-systems.  Distinct from the system decomposition model  Centralized control  One sub-system has overall responsibility for control and starts and stops other sub-systems  Event-based control  Each sub-system can respond to externally generated events from other sub-systems or the system’s environment N.L. Hsueh, SE-Lab IECS FCU 23 1. Centralized control Software Engineering  A control sub-system takes responsibility for managing the execution of other sub-systems  Call-return model  Top-down subroutine model  Control starts at the top of a subroutine hierarchy and moves downwards.  Applicable to sequential systems  Manager model  One system component controls the stopping, starting and coordination of other system processes.  Applicable to concurrent systems. N.L. Hsueh, SE-Lab IECS FCU 24 Software Engineering Call-return model Main program Routine 1 Routine 1.1 Routine 2 Routine 1.2 N.L. Hsueh, SE-Lab IECS FCU Routine 3 Routine 3.1 Routine 3.2 25 A centralized control Software Engineering model for a real-time system control Sensor processes Actuator processes System controller Computation processes N.L. Hsueh, SE-Lab IECS FCU User interface Fault handler 26 Software Engineering 2. Event-driven systems  Driven by externally generated events where the timing of the event is outside the control of the sub-systems which process the event  In centralized control models, control decisions are usually determined by the value of some system state variables  Two principal event-driven models  Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so  Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing N.L. Hsueh, SE-Lab IECS FCU 27 Software Engineering Broadcast model  Effective in integrating sub-systems on different computers in a network  Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event  Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them  However, sub-systems don’t know when an event will be handled Sub-system Sub-systemKK m1.registerTo(m2) m1.registerTo(m2) m2 m2receive receivean anevent event m2 m2will willcall callm1 m1 N.L. Hsueh, SE-Lab IECS FCU 28 Software Engineering Broadcasting Sub-system 1 Sub-system 2 Sub-system 3 Sub-system 4 Event and message handler N.L. Hsueh, SE-Lab IECS FCU 29 Software Engineering Interrupt-driven systems  Used in real-time systems where fast response to an event is essential  There are known interrupt types with a handler defined for each type  Each type is associated with a memory location and a hardware switch causes transfer to its handler  Allows fast response but complex to program and difficult to validate N.L. Hsueh, SE-Lab IECS FCU 30 Interrupt-driven control Software Engineering Interrupts Interrupt vector Handler 1 Handler 2 Handler 3 Handler 4 Process 1 Process 2 Process 3 Process 4 N.L. Hsueh, SE-Lab IECS FCU 31 Software Engineering Modular Decomposition N.L. Hsueh, SE-Lab IECS FCU 32 Software Engineering The problem that they have to deal with are complex, …, software engineers cannot reduce this complexity. However, it can be funneled and confined within weakly coupled closed areas. By judicious segmentation of the state space, the system is made easier N.L. Hsueh, SE-Lab IECS FCU 33 Software Engineering Modular decomposition  Sub-systems are decomposed into modules  Two modular decomposition models covered  An object model where the system is decomposed into interacting objects  A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model  If possible, decisions about concurrency should be delayed until modules are implemented N.L. Hsueh, SE-Lab IECS FCU 34 Software Engineering Object models  Structure the system into a set of loosely coupled objects with welldefined interfaces  Object-oriented decomposition is concerned with identifying object classes, their attributes and operations  When implemented, objects are created from these classes and some control model used to coordinate object operations  Adv:  loosely coupled: the implementation of objects can be modified without affecting other objects  Easily modeled: objects are often representations of real-world entities N.L. Hsueh, SE-Lab IECS FCU 35 Software Engineering Invoice processing system Customer customer # name address credit period Payment invoice # date amount customer # N.L. Hsueh, SE-Lab IECS FCU Receipt Invoice invoice # date amount customer invoice # date amount customer # Issue Send reminder Accept payment Send receipt 36 Software Engineering Data-flow models      Functional transformations process their inputs to produce outputs May be referred to as a pipe and filter model (as in UNIX shell) Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems Not really suitable for interactive systems Adv.  It supports the reuse of transformations  It is intuitive in that many people think of their work in terms of input and output processing  Evolving the system by adding new transformations is usually straightforward  It is simple to implement either as a concurrent or a sequential system N.L. Hsueh, SE-Lab IECS FCU 37 Software Engineering Invoice processing system Read issued invoices Invoices Issue receipts Receipts Find payments due Issue payment reminder Identify payments Reminders Payments N.L. Hsueh, SE-Lab IECS FCU 38 Software Engineering Domain-Specific Architecture N.L. Hsueh, SE-Lab IECS FCU 39 Software Engineering Domain-specific architectures  Architectural models which are specific to some application domain  Two types of domain-specific model  Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems  May be reused directly in a design  Bottom-up models  Reference models which are more abstract, idealized model. Provide a means of information about that class of system and of comparing different architectures  Used to communicate domain concepts and compare possible architecture  Top-down models N.L. Hsueh, SE-Lab IECS FCU 40 Software Engineering Generic models  Compiler model is a well-known example although other models exist in more specialized application domains  Lexical analyzer  Symbol table  Syntax analyzer  Syntax tree  Semantic analyzer  Code generator  Generic compiler model may be organized according to different architectural models N.L. Hsueh, SE-Lab IECS FCU 41 Software Engineering A data-flow model of a compiler Symbol table Lexical analysis Syntactic analysis N.L. Hsueh, SE-Lab IECS FCU Semantic analysis Code generation 42 The repository modelSoftware of a Engineering language processing system Lexical analyser Syntax analyser Semantic analyser Prettyprinter Abstract syntax tree Grammar definition Optimizer Editor Symbol table Output definition Code generator Repository N.L. Hsueh, SE-Lab IECS FCU 43 Reference architectures Software Engineering  Reference models are derived from a study of the application domain rather than from existing systems  May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated  OSI model is a layered model for communication systems N.L. Hsueh, SE-Lab IECS FCU 44 Software Engineering OSI reference model 7 Application Application 6 Presentation Presentation 5 Session Session 4 Transport Transport 3 Network Network Network 2 Data link Data link Data link 1 Physical Physical Physical Communications medium N.L. Hsueh, SE-Lab IECS FCU 45 Software Engineering Design Pattern N.L. Hsueh, SE-Lab IECS FCU 46 Software Engineering 我們不只要做絲襪 , 我們要做 ‘超彈性’絲襪 N.L. Hsueh, SE-Lab IECS FCU 47 Software Engineering What is a Pattern?  Current use comes from the work of the architect Christopher Alexander  Alexander studied ways to improve the process of designing buildings and urban areas  “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem and a solution.”  Hence, the common definition of a pattern: “A solution to a problem in a context.”  Patterns can be applied to many different areas of human endeavor, including software development N.L. Hsueh, SE-Lab IECS FCU 48 Software Engineering Why Pattern?  "Designing object-oriented software is hard and designing reusable object-oriented software is even harder." - Erich Gamma  Experienced designers reuse solutions that have worked in the past  Well-structured object-oriented systems have recurring patterns of classes and objects  Knowledge of the patterns that have worked in the past allows a designer to be more productive and the resulting designs to be more flexible and reusable N.L. Hsueh, SE-Lab IECS FCU 49 Software Engineering Histo ry  1987 - Cunningham and Beck used Alexander’s ideas to develop a small pattern language for Smalltalk  1990 - The Gang of Four (Gamma, Helm, Johnson and Vlissides) begin work compiling a catalog of design patterns  1991 - Bruce Anderson gives first Patterns Workshop at OOPSLA  1993 - Kent Beck and Grady Booch sponsor the first meeting of what is now known as the Hillside Group  1994 - First Pattern Languages of Programs (PLoP) conference  1995 - The Gang of Four (GoF) publish the Design Patterns book N.L. Hsueh, SE-Lab IECS FCU 50 Software Engineering Types of software patterns  Analysis  Design  Organizational  Process  Project Planning  Configuration Management N.L. Hsueh, SE-Lab IECS FCU 51 Software Engineering Types of software patterns  Riehle and Zullighoven in “Understanding and Using Patterns in Software Development” mention three types of software patterns  Conceptual Pattern  Pattern whose form is described by means of terms and concepts from the application domain  Design Pattern  Pattern whose form is described by means of software design constructs, such as objects, classes, inheritance and aggregation  Programming Pattern (Programming Idiom)  Pattern whose form is described by means of programming language constructs N.L. Hsueh, SE-Lab IECS FCU 52 Software Engineering Design Pattern Level of Abstraction  Complex design for an entire application or subsystem More abstract  Solution to a general design problem in a particular context More concrete  Simple reusable design class such as a linked list, hash table, etc. N.L. Hsueh, SE-Lab IECS FCU 53 Software Engineering GoF Design Patterns  The GoF design patterns are in the middle of these levels of abstraction  “A design pattern names, abstracts, and identifies key aspects of a common design structure that makes it useful for creating a reusable object-oriented design.”  The GoF design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” N.L. Hsueh, SE-Lab IECS FCU 54 Software Engineering GoF Classification Of Design Patterns  Purpose - what a pattern does  Creational Patterns  Concern the process of object creation  Structural Patterns  Deal with the composition of classes and objects  Behavioral Patterns  Deal with the interaction of classes and objects  Scope - what the pattern applies to  Class Patterns  Focus on the relationships between classes and their subclasses  Involve inheritance reuse  Object Patterns  Focus on the relationships between objects  Involve composition reuse N.L. Hsueh, SE-Lab IECS FCU 55 Software Engineering GoF Essential Elements Of Design Patterns  Pattern Name  Having a concise, meaningful name for a pattern improves communication among developers  Problem  What is the problem and context where we would use this pattern?  What are the conditions that must be met before this pattern should be used?  Solution  A description of the elements that make up the design pattern  Emphasizes their relationships, responsibilities and collaborations  Not a concrete design or implementation; rather an abstract description  Consequences  The pros and cons of using the pattern  Includes impacts on reusability, portability, extensibility N.L. Hsueh, SE-Lab IECS FCU 56 Software Engineering GoF Pattern Template  Structure A graphical representation of the pattern  Participants  The classes and objects participating in the pattern  Collaborations  How to do the participants interact to carry out their responsibilities?  Consequences  What are the pros and cons of using the pattern?  Implementation  Hints and techniques for implementing the pattern  N.L. Hsueh, SE-Lab IECS FCU 57 Software Engineering GoF Pattern Template  Pattern Name and Classification  A good , concise name for the pattern and the pattern's type  Intent  Short statement about what the pattern does  Also Known As  Other names for the pattern  Motivation  A scenario that illustrates where the pattern would be useful  Applicability  Situations where the pattern can be used N.L. Hsueh, SE-Lab IECS FCU 58 Software Engineering GoF Pattern Template  Sample Code  Code fragments for a sample implementation  Known Uses  Examples of the pattern in real systems  Related Patterns  Other patterns that are closely related to the pattern N.L. Hsueh, SE-Lab IECS FCU 59 Software Engineering Key points  The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model  System decomposition models include repository models, clientserver models and abstract machine models  Control models include centralised control and event-driven models N.L. Hsueh, SE-Lab IECS FCU 60 Software Engineering Key points  Modular decomposition models include data-flow and object models  Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models N.L. Hsueh, SE-Lab IECS FCU 61 Software Engineering The architectural model provides a Gestalt view of a system, allowing the software engineering to examine it as a whole R. Pressman N.L. Hsueh, SE-Lab IECS FCU 62