ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 40

Size: px
Start display at page:

Download "ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 40"

Transcription

1 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 40 Abstract A Complementary Approach to Requirements Engineering --Software Architecture Orientation Hong Mei Software Production Research, Bell Labs, Naperville, IL 60566, USA Software Engineering Lab, Peking University, Beijing , PRC <reel@research.bell-labs.corn, meih@pku.edu.cn> This paper presents the idea of Software Architecture Oriented Requirements Engineering, a complementary approach to existing requirements engineering processes and methods. The main objective is to introduce concepts and principles of software architecture into requirement analysis and requirement specification, supporting requirement reuse, traceability between requirement specifications and system design, and consistency in the whole software development process more effectively. The paper views connectors as the first-class entities in the problem space, not just in the soluti~ space as most of current research on software archite6tu~e dolws, hence the connector recognition and specification are same important as component recognition and specification in requirements engineering. Based on this idea, the paper presents a new sottware development process and corresponding requirements engineering process, gives some guidelines for connector recognition, and borrows the notations of software architecture description to specify the functional and behavioural requirements at a high abstraction level. It must be pointed out that the approach presented in this paper is not a substitute for existing ones, but a complement to them from another perspective and at a different abstraction level. Keywords: Requirements Engineering, Software Architecture, Connector, Component t. Introduction It is common sense that requirements engineering is an important phase in software engineering. In the last two decades, research on requirements engineering has made much progress, many systematic approaches have been presented and applied in software development practice. Because of the development of soilware production technology, including requirements engineering technology, the improvement in software productivity and quality is visible. But we must confess that there is a far way to reach what we really expect. Further research is needed. Requirements engineering is a complex research field, which consists of context, groundwork, acquisition, modelling & specification, analysis, measurement, and communication & documentation, etc [1]. Of course, all the aspects are important. But from the view of the following stage, software design, it is natural that more attentions are paid to modelling & specification. A consistent, complete, precise, and understandable specification is the basic premise for the following development activities. Keeping the traceability between requirement specifications and design, and the consistency in basic concepts between these two stages are the effective means to support quality and productive development. Looking back on the development of software development methodology, it is not difficult to find that keeping the traceability and the consistency in concepts between requirements and designs always are the goals that we pursue. For example, as we know, structured methodology originated in later 1960s in conjunction with the development of structured programming. Hitherto, there exist a lot of structured methods. But for each method, the traceability between structured analysis (SA) and structured design (SD) must be built. So, researchers have developed some techniques to map mechanically Data Flow Diagram (DFD) to Module Structure Chart (MSC) and to facilitate tracking forward or backward between structured requirement specifications and structured designs. DFD and MSC are two main tools widely used in SA and SD. Nevertheless, the differences between the basic concepts and principles of DFD and MSC make a gap between SA and SD, even there exist some automatic transformation~ from DFD to MSC. It is this gap that is viewed as one of the weaknesses of structured methods. In the last decade, the objectoriented (OO) methodology has become a prevalent paradigm to software development. One of the main benefits of OO p~digm is that it cured the symptom that the structured paradigm did not. The development of OO methodology is similar to the development of structured methodology. It originated from objectoriented programming. But because Object-Oriented Atmlysis (OOA) and Object-Oriented Design (OOD) use the uniform basic concepts and principles, the mapping between OO requirement specifications and OO design is natural and direct. Also, keeping traceability is easy and transformation could be done mechanically. The lessons learnt from the development of software development methodology are: new ideas and technologies usually oriiginate and are applied at the later stages in the software life cyclle, and eventually will be introduced into the early stages; the more uniform the concepts and principles used in software development are, the better and more powerful the methodology is. Recently, more and more researchers pay their attentions to the research on software architecture (SA, in the rest of this paper, the acronym SA stands for Software Architecture). SA has begun to emerge as a new and important research field for software engineering circle. There exists a consensus that for any larlge software system, its gross structure--that is, its high-level organisation of computational elements and interactions between those elements--is a critical aspect of design [21 [3]. It is widely accepted that SA is a very important product and software archtecting is a necessary phase in software life cycle. There is n doubt that SA, as an important design concept, will certainly ira. pact the software development methodology and process, inchid. ing requirements engineering. Actually, some resear,zh ha,,

2 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 41 pointed out that SA "can serve as the key milestone in the entire software life cycle process". SA's "support of the needs of system engineers, customers, developers, users, and maintainers, also implies that it is involved in all phases of the software and system life cycle" [4]. Therefore, it is natural and reasonable introducing SA concepts into requirements engineering. We can imagine, if we use conventional method to produce requirement specifications, it is relatively difficult for us to establish the mapping relationships between the requirement specifications and SA which is the product of the following phase--software architecting. On the other hand, from the views of reuse, we argue that it is also necessary to introduce SA concepts and principles into the requirement analysis and specifications. Requirement specifications also are important reusable assets. As we know, something is reusable if and only if it has reusable value in substance and has reusable possibility in its representation. SA improves reusability from two aspects. On the one hand, it lets us to explore and identify reusable assets. On the other hand, it gives us the means to make these reusable assets could be reused by other users. Introducing SA concepts into requirements engineering at least can let us organise requirement specifications in a constructive structure and a more reusable form. This paper tries to introduce concepts and principles of software architecture into the requirement analysis and specification, supporting requirement reuse, traceability between requirement specifications and system design, and consistency in whole software development process more effectively. The main idea is to view connectors as the first-class entities in the problem space, not just in the solution space (so far, most Of research on SA just views connectors as the first-class entities in the design space. We argue that it is not enough), hence the connector recognition and specification as the same important activity as component recognition and specification in requirements engineering. The paper presents a new software development process and corresponding requirements engineering process, gives some guidelines for conhector recognition, and borrows the notations of software architecture description to specify the functional and behavioural requirements at a high abstraction level. This is a complementary approach to existing requirements engineering processes and methods. We can call it Software Architecture Oriented Requirements Engineering. The rest of this paper is organised as follows. Section 2 gives a brief introduction to software architecture and a discussion about connector, viewing connectors as first-class entities in problem space. Section 3 presents a software architecture-based development process. Section 4 discusses how to achieve SA-oriented requirement analysis and specification; a set of guidelines is given. Section 5 concludes the paper and lists some future research issues. 2. Software Architecture and Connector For large, complex software system, the design of the overall system structure, that is, software architecture, is a critical design problem. This is why SA has become a focus for research. But unfortunately, to date there is no standard, universally-accepted definition of software architecture. SA has been defined in various ways, some important definitions arc as follows: it is a structure composed of components, and rules characterising the interaction of these components [5], it consists of elements, form and rationale[3], it consists of components, connectors and configuration[2], it is a structure which comprises software components, the externauy visible properties of those components, and the relationships among them[6], or it is a collection of software and system components, connections, and constraints, a collection of system stakeholders' need statements, and a rationale [4]. However, from these definitions, we can at least conclude a common core-- components and connectors (connections or interactions). Actually, for any system, components and connectors are the main entities which constitute the system. In fact, any software system has architecture, even no architecture design was made or the architecture was not documented explicitly. For these systems, the architectures are hidden in the systems (in source code or executable code). We can identify the components in a system, which are the modules composing the system. But it is relatively difficult to identify independent connectors, because the connections between components are sc~er~ ~!hardwritten) in those modules. It is natural, for this kin"d of systems, there are some inherent flaws. One is that reusing the components... in these systems is difficult. Another is that the evolution and maintenance of these systems are difficult. Obviously, due to the lack of sound architectures, the development of this kind of systems probably had spent more time and efforts, and left more bugs. Research and practice of SA aim at making the architecture of a system explicit, dealing with at a higher-level the design issues such as gross organisation and control structure, assignment of functionality to computational units, and high-level interactions between these units [7]. One of the most important contributions of SA research is making the connectors explicit, viewing conhectors as the first-class entities in the system. Making connectors, which formerly were hidden and scattered in the modules of system, explicit and independent provides a means to view, design system and reason system behaviors and properties at a higher abstraction level, to design and implement more reusable components, and even to reuse some connectors. Now there are many connectors which have been identified and studied, such as procedure call, data sharing, file I/0, RPC, RTScheduler, PLBundler, pipes, event broadcast, client-server protocols, etc [8] [9]. Also there is some research involved in user-defined connectors [9] and composition of connectors [10]. This kind of research just treats connectors as first-class entities in the design phase, that is, viewing connector as a design concept. But actually, in the problem space, there exist connectors too. It is necessary to introduce connector concept into the modelling of problem space and view connectors as the first-class entities in the requirement specifications, giving them equal position as components in problem space. In component-based software development, components are the main entities which exist in whole life cycle process and are used in requirement specifications, system designs and executable programs. Here we argue that we should treat connectors in same way. Let us look at a simple example, producer-consumer application.

3 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 42 Based on the analysis to the problem space, it is easily to identify Producer and Consumer as two components, each encapsulating a set of coherent functionality. Now we study the interactions between these two components from the perspective of user requirements. In reality, there exist many different interaction modes due to different cases. Following are some possibilities: 1) Producer produces one product, then sends it to Consanner and gets receipt, Consumer consumes it. In this case, there is a synchronisation between active Producer and passive Consumer, and the sequence of products is kept, that is~ first produced, first consumed. 2) Consumer sends request to Producer, waits the product and gets it, then consumes it. In this case, there is a synchronisation between passive Producer and active Consumer, and the sequence of products is kept, that is, first produced, first consumed. 3) Producer produces products and piles them up somewhere continuously, Consumer gets products from the same place and consumes them continuously, no receipt nor request is needed. In this case, Producer and Consumer work relatively independently, no sequence of products is kept, and losing products is possible. 4) Producer produce product and store it into a warehouse, Consumer gets product from warehouse and consumes it. In this case, whether the warehouse has some functionality and how complex its functionality are will be a key factor for requirement analysis and specification, what can be determined are that Producer and Consumer work independently, and losing products is not permitted. From above cases, we can see that these actually are 4 different connections between Producer and Consumer. These are connections between components in the problem space, not in the solution space. So, this is a requirement problem, not a design problem. This example just shows that it is necessary to make the connections between components in the problem space explicit. In requirement specifications, explicit connection specifications let the documentation have sound structures, supporting reuse and traceability more effectively. Using components and connectors as the main constituents for requirement specifications, we can document requirement specifications in the uniform way with SA, forming a consistent development process. Connectors in problem space will be refined or implemented in design space. Of course, for any connector in problem space, there exist many different kinds of implementation in design. For example, in above 4 connections, connection 1 and 2 could be implemented by using message passing (procedure call), pipes, event broadcast or RPC, connection 3 by data sharing or file I/O. For case 4, the situation may be somewhat complicated. In the simplest case, we can use data sharing too. But if the warehouse has some functionality such as simple management of products, then we can not use some primitive or simple connectors to implement it, the user-defined connector is needed. In the more complicated case, the warehouse has powerful management functions. In essence, the warehouse has become an important functional unit, hence, it is not simply a connection, it virtually is a component in the system. In this case, the system specifications will consist of 3 components and 2 connectors. This case shows that the identification of components and connectors in the problem space is determined by the application requirements. Now we have made the connectors become a concept tn;ed in every life-cycle phase. It is this concept, along with the concept of components, that forms a uniform means to specify the artifacts in the development process, and further sets a foundation for a consistent SA-oriented software development method. The connectors can be divided into 3 classes according to different phases. There are connectors in problem space, connectors in design space, and connectors in final executable system. Following are some dtiscussions on these 3 classes of connectors: Connectors in problem space: This class of connectors is identified from the user requirement definitions. In fact, these connectors specify the interaction protocols between components. We can divide relatively these connecto~ into two categories--complex and simple. The simple connectors are those whose interaction protocols are relatively simple, so they can be refined or implemented by some existing conhectors in design space. For example, one simple connector may just specify a data-passing protocol. It can be implemented easily by pipes, data sharing, or even procedure call in design. The complex connectors are those which can not be implemented directly by existing connectors in design, hence, user-defined connectors are needed. Of course, in requirement specifications, we are not concerned the difference. We just identify and specify them. The implementation is a design-decision problem. Connectors in design space: This class of connectors is the refinement or implementation of the problem-space connectors. According to their forms, they can be divided into userdefined connectors and primitive connectors (some commonaccepted ones such as pipes, data sharing, etc). A userdefined connector may specify a complex protocol, so it is possible that it will be modelled by a set of objects. According to their roles in design, these connectors can be divided into real connectors and artificial connectors. The former are those which are the direct implementation of some problemspace connectors. The later are those which are come ur with in the design phase just from software's view (they arc brought in due to the existence of some artificial component~ that are introduced at the design phase and have no dire~ corresponding components in the problem space), noll corre. sponding to some problem-space connectors. Connectors in final system: This class of connector,,; is th~ final implementation of connectors in design. Design con. nectors can be implemented in two ways. For most user. defined connectors, they are implemented in concrete pro. gram modules. So, these connectors are independent entitiez in system. We can call them user-implemented connectors For those primitive connectors, their implementation depenc on the infrastructure provided by the platform, such as fa cilities provided by programming language, OS, and som~ middieware. They are called infrastructure-based comaectors From the view of user programs, these connectors do nc

4 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 43 have independent forms. By the way, we should point out that in general sense, connectors are some special kind of components. The key difference is that components are computational units and connectors are communication units. Both are important constituents in system. 3. A Software Architecture based Development Process Traditional software development processes usually do not con- sider deeply the design issues on the architectural level. But if we view software architecture as an important artifact, even as the reference model in the whole life-cycle, we must adapt the development process so that it suits SA-based software development. As a basic agreement, many people think that an architecting phase is needed, which will be after requirement analysis and before design. In Figure 1, a new version of waterfall model for process is shown. ~equirement~architecting~ Design ~ Coding ~ Testing ~Maintenanc~ Figurel. New version of waterfall model Based on our discussion above, we argue that although this model takes account of the architecture design, it is not enough to stress the importance of architecture and to describe a SA-centred process, especially how to specify requirements in terms of SA concepts. When we will begin the architecting phase? Can we just do architecting after requirements engineering ends? In our opinions, Software architecture is at a higher abstraction level, therefore the architecture design does not needed to know all detailed requirement specifications, just some higher level specifications are enough. On the other hand, it is necessary to specify the requirements at a higher level in term of SA concepts, and it is also nec- essary to get feedback from architects to guide detailed requirement analysis and specification. Based on this idea, we present a SA-based process model as shown in Figure 2. Because supporting reuse is one of our goals, this process model is combined with OO paradigm. There are three reasons for this choice. Firstly, OO has become the prevalent paradigm in software development. Secondly, OO provides more technical support to reuse. Thirdly, main component standards (such as CORBA, COM/DCOM, and EJB) are based on OO paradigm. Of course, combining non-oo paradigm into this process is also possible. r Requirements $A-oriented ~ Software ] Analysis [~ [ Architecting \/ \\ Object-oriented ~ requirements Anal)'sis Object-oriented Software ~ Implementation Testing Maintenance Design Figure 2. A SA-based Software Process Model This model is a variant of the waterfall model too. The main differences are in the Requirements and Design phases. From the viewpoint of the modem software engineering, requirements and design are very important phases in the software life-cycle. In this model, SA and OO concepts are used uniformly throughout the entire software development process, especially SA, used as the reference model for each phase in the life-cycle. Two new phases, SA-oriented requirement analysis and SA design, are introduced into the conventional development process. They focus on system properties at a higher level of abstraction. In substance, this model is not a substitute to conventional model, but an enhancement or modification. Following are the brief descriptions of every phase in this model, mainly focusing on activities and artifacts in each phase. SA-orientcd requirement analysis: Main activities include determining the boundary of the problem space, identifying the system users and their responsibilities, exploring the overall external behaviors from user's perspective, identifying components and connectors, specifying the components and connectors, producing SA-oriented higher level requirement specification, checking the specifications. These activities are conducted iteratively. The feedback from the following phases will also lead to a new iteration. The artifact in the phase is SA-oriented requirement specifications, including component specifications and connector specifications. This artifact will be used as the basis for software architecting and further OO analysis. Also, it is a very useful complement to conventional requirement documentation from a higher level perspective. Software Architecting: In this phase, SA-oriented require-

5 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 44 merit specifications are refined in the architectural design of system, and some overall design decisions are made. Main activities include studying the SA-oriented requirement specifications, refining components and connectors in the problem space, creating necessary artificial components and connectors, producing software architecture design (including dynamic and static models), building mapping relationships between requirement specifications and SA, checking SA, presenting some hints for OOA and some constraints for OOD. The artifact in this phase is the SA design of the system, which is the reference model for the system development. Object-oriented requirement analysis: In this phase, based on the higher level requirement specifications produced in the early requirements phase, and some heuristics from architecting phase, detailed and complete requirement specifications are made. The main activities in this phase are similar to those in conventional OOA. The only difference is that, in the early requirements phase, the problem space has been partitioned properly, hence in this phase, we do OOA to every subsystem (a component or a set of components, along with relevant connectors), then integrate the results into a final documentation. The artifact in this phase is the final requirement specifications, consisting of various models used by conventional OOA plus the higher level specifications produced by SA-oriented analysis. Object-oriented software design: In the phase, based on the SA design and detailed requirement specifications, the detailed and complete design of system is made. The main activities in this phase are similar to those in conventional OOD. The artifact in this phase is the system design, consisting of various models from different perspectives. It is the refinement and implementation of SA and to requirement specifications and is used to guide system implementation. In this phase, designers should try their best to reuse existing components, connectors, design patterns, and frameworks. Implementation: In this phase, coding is made according to the system design, including implementation of components and conncetors, and system integration. Testing: In this phase, testing of the system is conducted, including class testing, component testing, connector testing and integration testing. Maintenance: In this phase, system is maintained and evolved, keeping the almost same software architecture. 4. Software Architecture Oriented Requirement Analysis and Specification In last section, we have presented a SA-based software development process whose main features are SA-centred development support and SA-oriented requirement analysis. In this section, we will focus on the discussion of SA-oriented requirement analysis and specification. The objective of this phase is to generate system's SA-oriented requirement specifications at a higher level of abstraction. The main activities are listed as follows: Determine the boundary of the problem space Identify the system users and their responsibilities Explore the overall external behaviors from user's perspective Identify components and connectors Specify the components and connectors Produce SA-oriented higher level requirement specific~itions Check the specifications These activities are conducted iteratively. Following are brief descriptions of these activities. As we mentioned, our appreach is just a modification and a complement to conventional approach, so we do not describe all activities in details. Only those new ideas are discussed. Determine the boundary of problem space For any requirement analysis method, determining boundary is always the first step and an important step. So, here the traditional techniques and tools are useful. Identify the system users and their responsibilities This is an important step. By identifying the users of the system and their responsibilities, we can figure out the relationskips between system and outside easily. It is helpful for us to explore system functions and behaviors, and to partition the system into subsystems or components. Explore the overall external behaviors from user's perspective In this step, we view the system as a black box.and explore its overall behaviors from different views, according to different user's perspectives. It will produce a top-level model of 10de system. Use Case method [11] is an effective means for this step. For each user, relevant use cases are identified. Then all use cases are analysed, conflicts and consistencies are solved, and finally all use cases are divided into some groups, in each group use cases are coherent. Grouping of use cases is a good guide to partition the system. Identify components and connectors Based on the information obtained from the early steps, we starl to identify the components and connectors in the problem space, then divide them into different subsystems. Following is a set oj guidelines to identify these entities: Study the context where the software system will be used. Organisational units and physical equipment are candidate,, for components. Connections and relationships betweer these entities are candidates for connectors. Study the overall external behaviors of the system. Eacl0 group of use cases manifests some external behavior, the entities in the system which involved in the provision of thal behavior are candidates for components. Connections and relationships between these entities are candidates tbr con. nectors. If some entity in the problem space has relatively independ.

6 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 45 ent functionality, which is constituent of system functionality, then that entity may be considered as a component. If it has much dependency on other entities to achieve its functionality, it should be considered as an object which will be combined with other objects to form a component. The difference between components and connectors is that components are the computational units which provide some functions or behavior, and connectors are just the interactions between components, which do not have direct contribution to some external behaviors. If some computational entity has very simple functions and these functions do not have direct contribution to the external behaviors, then it may be considered as an object, or even as a connector. If some connector represent a complex interaction protocol, then it may be considered as a component. Based on the dependencies between components, all components are divided into different subsystems. One subsystem may contain one or more components. Refine the top-level use case diagram, checking the necessity of identified components and connectors. In this step, some techniques used to identify subjects or subsystems in conventional OO analysis may be useful. Specify the components and connectors In this step, every component and connector are specified independently, in order to support potential reuse. Existing IDLs (Interface Description Languages), ADLs (Architecture Description Languages), STC (State Transition Chart), and use case diagram are useful tools to specify components and connectors. Some nonfunctional specifications may be adhered to these specifications. Produce SA-oriented high-level requirement specifications In this step, we will combine the specifications of components and connectors to form overall specifications for system requirements. Existing ADLs are the best tools to achieve this goal. Some nonfunctional specifications may be contained. Check the specifications In this step, we will check some properties of the SA-oriented requirement specifications, including completeness, consistency, and deadlock freeness, etc. Some techniques for SA checking may be useful here. 5. Conclusion In this paper, a complementary approach to requirements engineering is presented. The key ideas are viewing sorware architecture as the reference model in the software development process, viewing connectors as the first-class entities in the problem space, and introducing the SA concepts and principles into the requirement specifications at a higher-level abstraction. A SA-based software development process is presented and discussed, and a special attention is paid to SA-oriented requirement analysis and specification. We argue that this approach will be helpful to support requirement reuse, traceability between re- quirement specifications and system design, and consistency in whole software development process. This approach can be combined with existing software development methods, especially the OO methods to provide more effective development support. We must confess that this paper is just an elementary research. But we do believe that the idea is useful, and this approach will work. Hence further research will be necessary. The main research issues are as follows: Providing a complete and consistent SA-centred software development methodology, including a set of guidelines to guide the development activities, a more formally defined process model, and relevant tools and notations, etc. Combined with the research on SA, exploring the composition of components at different abstraction levels. Using this approach experimentally in the practical projects to get evaluations. Acknowledgements This effort gets support from Bell-Labs China and Software Production Research of Bell-Labs while the author works at Software Production Research Department. The author would like to thank David Weiss for his useful comments and suggestions on the draft. References [1] Finkelstein, A. Requirements Engineering: a review and research agenda, in Proc 1 st Asian & Pacific Software Engineering Conference, (IEEE CS Press) [2] David Garlan and Mary Shaw, An Introduction to SoRware Architecture, In Advances in Software Engineering and Knowledge Engineering, Volume 1, World Scientific Publishing Company, [3] Dewayne E. Perry and Alexander L. Wolf, Foundations for the Study of Software Architecture, ACM SIGSOFT Software Engineering Notes, 17(4), [4] Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, and Barry Boehm, On the Definition of Soft'ware System Architecture, ICSE 17 Sottware Architecture Workshop, [5] A.K. Jones, The Maturing of Software Architecture, Software engineering Symposium, Software Engineering Institute, Pittsburgh, August [6] Bass, Clements, and Kazman. SoRware Architecture in Practice, Addison-Wesley 1997 [7] Robert Allen and David Garlan, Formalizing Architectural Connection, ICSE 16, Italy, May, [8] Robert Allen and David Garlan, Beyond Definition/Use: Architectural Interconnection, Workshop on Interface Definition Languages, Oregon, January, [9] M. Shaw, R. Deline, D.V. Klein, T.L Ross, D.M. Young, and G. Zelesnik, Abstractions for Software Architecture and Tools to Support Them, IEEE Transactions on Software Engineering, April [10] David Garlan, Higher-Order Connectors, Workshop on Compositional Software Architectures, Monterey, CA, January [11] I. Jacobson, et al, Object-Oriented Sottware Engineering, A Use Case Driven Approach, Addison-Wesley, 1992.

Architectural Blueprint

Architectural Blueprint IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint

More information

Using Architectural Models at Runtime: Research Challenges

Using Architectural Models at Runtime: Research Challenges Proceedings of the European Workshop on Software Architectures, St. Andrews, Scotland, May 2004. Using Architectural Models at Runtime: Research Challenges David Garlan and Bradley Schmerl Department of

More information

Capturing Design Expertise in Customized Software Architecture Design Environments

Capturing Design Expertise in Customized Software Architecture Design Environments Capturing Design Expertise in Customized Software Architecture Design Environments Robert T. Monroe School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213 Abstract: Software architecture

More information

Lecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802

Lecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802 UNIT-II Lecture Notes On UML IMPORTANCE OF MODELING, BRIEF OVERVIEW OF OBJECT MODELING TECHNOLOGY (OMT) BY RAMBAUGH, BOOCH METHODOLOGY, USE CASE DRIVE APPROACH (OOSE) BY JACKOBSON. KHALID AMIN AKHOON 1

More information

INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2

INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:

More information

CS560 Lecture: Software Architecture Includes slides by I. Sommerville

CS560 Lecture: Software Architecture Includes slides by I. Sommerville CS560 Lecture: Software Architecture 2009 Includes slides by I. Sommerville Architectural Design Design process for identifying the sub-systems making up a system and the framework for sub-system control

More information

Architecture. Readings and References. Software Architecture. View. References. CSE 403, Spring 2003 Software Engineering

Architecture. Readings and References. Software Architecture. View. References. CSE 403, Spring 2003 Software Engineering Readings and References Architecture CSE 403, Spring 2003 Software Engineering http://www.cs.washington.edu/education/courses/403/03sp/ References» Software Architecture, David Garlan, CMU, 2001 http://www-2.cs.cmu.edu/~able/publications/encycse2001/»

More information

Quality-Driven Architecture Design Method

Quality-Driven Architecture Design Method Quality-Driven Architecture Design Method Matinlassi Mari, Niemelä Eila P.O. Box 1100, 90571 Oulu Tel. +358 8 551 2111 Fax +358 8 551 2320 {Mari.Matinlassi, Eila.Niemela}@vtt.fi Abstract: In this paper

More information

Architecture. CSE 403, Winter 2003 Software Engineering.

Architecture. CSE 403, Winter 2003 Software Engineering. Architecture CSE 403, Winter 2003 Software Engineering http://www.cs.washington.edu/education/courses/403/03wi/ 21-February-2003 cse403-14-architecture 2003 University of Washington 1 References Readings

More information

An Architecture-Based Approach for Component-Oriented Development

An Architecture-Based Approach for Component-Oriented Development An Architecture-Based Approach for Component-Oriented Development Feng Chen, Qianxiang Wang, Hong Mei, Fuqing Yang Department of Computer Science and Technology, Peking University, Beijing 100871, P.R.China

More information

Software Architectures

Software Architectures Software Architectures Richard N. Taylor Information and Computer Science University of California, Irvine Irvine, California 92697-3425 taylor@ics.uci.edu http://www.ics.uci.edu/~taylor +1-949-824-6429

More information

What is your definition of software architecture?

What is your definition of software architecture? What is your definition of software architecture? WHAT IS YOUR DEFINITION OF SOFTWARE ARCHITECTURE? The SEI has compiled a list of modern, classic, and bibliographic definitions of software architecture.

More information

5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered

5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process

More information

Pattern-Based Architectural Design Process Model

Pattern-Based Architectural Design Process Model Pattern-Based Architectural Design Process Model N. Lévy, F. Losavio Abstract: The identification of quality requirements is crucial to develop modern software systems, especially when their underlying

More information

Chapter 2 Overview of the Design Methodology

Chapter 2 Overview of the Design Methodology Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed

More information

SCOS-2000 Technical Note

SCOS-2000 Technical Note SCOS-2000 Technical Note MDA Study Prototyping Technical Note Document Reference: Document Status: Issue 1.0 Prepared By: Eugenio Zanatta MDA Study Prototyping Page: 2 Action Name Date Signature Prepared

More information

Transformation of analysis model to design model

Transformation of analysis model to design model 2010 International Conference on E-business, Management and Economics IPEDR vol.3 (2011) (2011) IACSIT Press, Hong Kong Transformation of analysis model to design model Lalji Prasad Truba College of Engineering

More information

Introduction. ADL Roles

Introduction. ADL Roles Architecture Description Languages (ADLs) 1 Introduction Architecture is key to reducing development costs development focus shifts to coarse-grained elements Formal architectural models are needed ADLs

More information

A Model Transformation from Misuse Cases to Secure Tropos

A Model Transformation from Misuse Cases to Secure Tropos A Model Transformation from Misuse Cases to Secure Tropos Naved Ahmed 1, Raimundas Matulevičius 1, and Haralambos Mouratidis 2 1 Institute of Computer Science, University of Tartu, Estonia {naved,rma}@ut.ee

More information

Modeling Systems Using Design Patterns

Modeling Systems Using Design Patterns Modeling Systems Using Design Patterns Jaroslav JAKUBÍK Slovak University of Technology Faculty of Informatics and Information Technologies Ilkovičova 3, 842 16 Bratislava, Slovakia jakubik@fiit.stuba.sk

More information

Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does

Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does To appear in Proceedings of 8th International Workshop on Software Specificatin and Design, March 1996 Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does Mary Shaw

More information

Lecture 1. Chapter 6 Architectural design

Lecture 1. Chapter 6 Architectural design Chapter 6 Architectural Design Lecture 1 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process

More information

A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWARE-IN-LOOP SIMULATION OF SAFETY CRITICAL SYSTEMS

A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWARE-IN-LOOP SIMULATION OF SAFETY CRITICAL SYSTEMS A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWARE-IN-LOOP SIMULATION OF SAFETY CRITICAL SYSTEMS YUJUN ZHU, ZHONGWEI XU, MENG MEI School of Electronics & Information Engineering, Tongji University,

More information

On ADLs and tool support for documenting view-based architectural descriptions

On ADLs and tool support for documenting view-based architectural descriptions On ADLs and tool support for documenting view-based architectural descriptions Danny Weyns Alexander Helleboogh SATURN 2008, Software Engineering Institute, CMU DistriNet Labs @ Dept.Computer Science K.U.Leuven

More information

An Approach to Software Architecture Analysis for Evolution and Reusability

An Approach to Software Architecture Analysis for Evolution and Reusability An Approach to Software Architecture Analysis for Evolution and Reusability Chung-Horng Lung, Sonia Bot, Kalai Kalaichelvan Rick Kazman 1 Software Engineering Analysis Lab. Department of Computer Science

More information

Chapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design

Chapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design

More information

An Approach to Software Component Specification

An Approach to Software Component Specification Page 1 of 5 An Approach to Software Component Specification Jun Han Peninsula School of Computing and Information Technology Monash University, Melbourne, Australia Abstract. Current models for software

More information

Chapter 6 Architectural Design. Chapter 6 Architectural design

Chapter 6 Architectural Design. Chapter 6 Architectural design Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying

More information

Analyzing the Product Line Adequacy of Existing Components

Analyzing the Product Line Adequacy of Existing Components Analyzing the Product Line Adequacy of Existing Components Jens Knodel and Dirk Muthig Fraunhofer Institute for Experimental Software Engineering (IESE), Fraunhofer-Platz 1, D-67663 Kaiserslautern, Germany

More information

Achieving Goals through Architectural Design Decisions

Achieving Goals through Architectural Design Decisions Journal of Computer Science 6 (12): 1424-1429, 2010 ISSN 1549-3636 2010 Science Publications Achieving Goals through Architectural Design Decisions Lena Khaled Department of Software Engineering, Faculty

More information

Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach

Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Ninat Wanapan and Somnuk Keretho Department of Computer Engineering, Kasetsart

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Style-specific techniques to design product-line architectures

Style-specific techniques to design product-line architectures Style-specific techniques to design product-line architectures Philippe Lalanda Thomson-CSF Corporate Research Laboratory Phone: 33 1 69 33 92 90 Email: lalanda@thomson-lcr.fr Domaine de Corbeville 91404

More information

Scenarios, Quality Attributes, and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures

Scenarios, Quality Attributes, and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures Scenarios, Quality Attributes, and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures Muhammad Ali Babar National ICT Australia Ltd. and University of New South

More information

Lecture 2: Software Engineering (a review)

Lecture 2: Software Engineering (a review) Lecture 2: Software Engineering (a review) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Credit where Credit is Due Some material presented in this lecture is

More information

Towards Software Architecture at Runtime

Towards Software Architecture at Runtime Towards Software Architecture at Runtime Authors Names Department of Computer Science and Technology Peking University, Beijing, PRC, 100871 +86 10 62757801-1 { @ cs.pku.edu.cn 1. Introduction Abstract

More information

ISO/IEC/ IEEE INTERNATIONAL STANDARD. Systems and software engineering Architecture description

ISO/IEC/ IEEE INTERNATIONAL STANDARD. Systems and software engineering Architecture description INTERNATIONAL STANDARD ISO/IEC/ IEEE 42010 First edition 2011-12-01 Systems and software engineering Architecture description Ingénierie des systèmes et des logiciels Description de l'architecture Reference

More information

Ch 1: The Architecture Business Cycle

Ch 1: The Architecture Business Cycle Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures

More information

How Should Patterns Influence Architecture Description Languages?

How Should Patterns Influence Architecture Description Languages? Thi d d i h F M k 4 0 4 Working paper for DARPA EDCS community How Should Patterns Influence Architecture Description Languages? A Call for Discussion Mary Shaw and Paul Clements Computer Science Department

More information

Lecture 13 Introduction to Software Architecture

Lecture 13 Introduction to Software Architecture Lecture 13 Introduction to Software Architecture Software Systems Design and Implementation ITCS/ITIS 6112/8112 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at

More information

Architectures in Context

Architectures in Context Architectures in Context Software Architecture Lecture 2 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Learning Objectives Understand architecture in its relation

More information

Comparative Analysis of Architectural Views Based on UML

Comparative Analysis of Architectural Views Based on UML Electronic Notes in Theoretical Computer Science 65 No. 4 (2002) URL: http://www.elsevier.nl/locate/entcs/volume65.html 12 pages Comparative Analysis of Architectural Views Based on UML Lyrene Fernandes

More information

10조 이호진 이지 호

10조 이호진 이지 호 10 조 200910045 이호진 200911415 이지호 According to the IEEE definition, design is.. The process of defining the architecture, components, interfaces, and other characteristics of a system or component 1.

More information

On the Role of Connectors in Modeling and Implementing Software Architectures

On the Role of Connectors in Modeling and Implementing Software Architectures On the Role of Connectors in Modeling and Implementing Software Architectures Peyman Oreizy, David S. Rosenblum, and Richard N. Taylor Department of Information and Computer Science University of California,

More information

Architectural Blueprint The 4+1 View Model of Software Architecture. Philippe Kruchten

Architectural Blueprint The 4+1 View Model of Software Architecture. Philippe Kruchten Architectural Blueprint The 4+1 View Model of Software Architecture Philippe Kruchten Model What is a model? simplified abstract representation information exchange standardization principals (involved)

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 7 Integrated Object-Oriented Methodologies: OPEN and FOOM 1 Object-oriented Process, Environment and Notation (OPEN) First introduced in

More information

An Information Model for High-Integrity Real Time Systems

An Information Model for High-Integrity Real Time Systems An Information Model for High-Integrity Real Time Systems Alek Radjenovic, Richard Paige, Philippa Conmy, Malcolm Wallace, and John McDermid High-Integrity Systems Group, Department of Computer Science,

More information

CS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS

CS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS 1. Explain iterative waterfall and spiral model for software life cycle and various activities

More information

SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA

SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA PURPOSE OF THIS CLASS An introduction to software architecture What is an architecture Why it is important How it is represented

More information

System Analysis and Design

System Analysis and Design System Analysis and Design 1 Introduction to Software Engineering Building Software is a complex exercise. Software is produced in several stages. Each stage attempts to deal with a different aspect of

More information

A Study of Bad Smells in Code

A Study of Bad Smells in Code International Journal for Science and Emerging ISSN No. (Online):2250-3641 Technologies with Latest Trends 7(1): 16-20 (2013) ISSN No. (Print): 2277-8136 A Study of Bad Smells in Code Gurpreet Singh* and

More information

Objectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture

Objectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture Objectives Architectural Design To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural

More information

Describing Information Systems Moving Beyond UML

Describing Information Systems Moving Beyond UML Describing Information Systems Moving Beyond UML Eoin Woods Artechra eoin@artechra.com Nick Rozanski Artechra nick@artechra.com Timetable 10:00-10:10 Introductions 10:10-10:25 - Presentation: Architectural

More information

From Goal-Oriented Requirements to Architectural Prescriptions: The Preskriptor Process

From Goal-Oriented Requirements to Architectural Prescriptions: The Preskriptor Process From Goal-Oriented Requirements to Architectural Prescriptions: The Preskriptor Process Manuel Brandozzi UT ARISE Advanced Research in Software Engineering The University of Texas at Austin manuelbr@mail.utexas.edu

More information

CSCI 3130 Software Architectures 1/3. February 5, 2013

CSCI 3130 Software Architectures 1/3. February 5, 2013 CSCI 3130 Software Architectures 1/3 February 5, 2013 Software Architecture What is a Software Architecture? The description of the structure of a software system, which is composed of software elements,

More information

Modeling variability with UML

Modeling variability with UML Modeling variability with UML Matthias Clauß Intershop Research Software Engineering Group Intershop, Jena Dresden University of Technology Matthias.Clauss@gmx.de Keywords: product families, domain modeling,

More information

Chapter 6 Architectural Design

Chapter 6 Architectural Design Chapter 6 Architectural Design Chapter 6 Architectural Design Slide 1 Topics covered The WHAT and WHY of architectural design Architectural design decisions Architectural views/perspectives Architectural

More information

Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila

Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Software Design and Architecture Software Design Software design is a process of problem-solving

More information

The Method for Verifying Software Architecture with FSP Model

The Method for Verifying Software Architecture with FSP Model The Method for Verifying Software Architecture with FSP Model Kim, Jungho SKC&C Inc., SK u-tower 25-1, Jeongja-dong, Bundang-gu, Seongnam-si, Gyeonggi-do 463-844, Korea kimjh@skcc.com Abstract C&C view

More information

The Past, Present and Future of Software Architecture

The Past, Present and Future of Software Architecture The Past, Present and Future of Software Architecture Eoin Woods UBS Investment Bank eoin@artechra.com www.eoinwoods.info About me I m a working software architect Always worked as a software engineer

More information

The Analysis and Design of the Object-oriented System Li Xin 1, a

The Analysis and Design of the Object-oriented System Li Xin 1, a International Conference on Materials Engineering and Information Technology Applications (MEITA 2015) The Analysis and Design of the Object-oriented System Li Xin 1, a 1 Shijiazhuang Vocational Technology

More information

Software Engineering

Software Engineering Software Engineering chap 4. Software Reuse 1 SuJin Choi, PhD. Sogang University Email: sujinchoi@sogang.ac.kr Slides modified, based on original slides by Ian Sommerville (Software Engineering 10 th Edition)

More information

Architectural Design

Architectural Design Architectural Design Objectives To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural

More information

Quality-Driven Conformance Checking in Product Line Architectures

Quality-Driven Conformance Checking in Product Line Architectures Quality-Driven Conformance Checking in Product Line Architectures Femi G. Olumofin and Vojislav B. Mišić University of Manitoba, Winnipeg, Manitoba, Canada Abstract Software product line are often developed

More information

Domain Engineering And Variability In The Reuse-Driven Software Engineering Business.

Domain Engineering And Variability In The Reuse-Driven Software Engineering Business. OBM 7 -draft 09/02/00 1 Domain Engineering And Variability In The Reuse-Driven Software Engineering Business. Martin L. Griss, Laboratory Scientist, Hewlett-Packard Laboratories, Palo Alto, CA. Effective

More information

Software Architecture and Design I

Software Architecture and Design I Software Architecture and Design I Instructor: Yongjie Zheng February 23, 2017 CS 490MT/5555 Software Methods and Tools Outline What is software architecture? Why do we need software architecture? How

More information

A Comparative Analysis of Architecture Frameworks

A Comparative Analysis of Architecture Frameworks A Comparative Analysis of Architecture Frameworks Antony Tang Jun Han Pin Chen School of Information Technology DSTO C3 Research Centre Swinburne University of Technology Department of Defence Melbourne,

More information

Configuration Management for Component-based Systems

Configuration Management for Component-based Systems Configuration Management for Component-based Systems Magnus Larsson Ivica Crnkovic Development and Research Department of Computer Science ABB Automation Products AB Mälardalen University 721 59 Västerås,

More information

Runtime Software Architecture Based Software Evolution And Adaptation

Runtime Software Architecture Based Software Evolution And Adaptation Runtime Software Architecture Based Software Evolution And Adaptation Qianxiang Wang, Gang Huang, Junrong Shen, Hong Mei, Fuqing Yang Department of Computer Science and Technology, Peking University 100871

More information

Meta Architecting: Towered a New Generation of Architecture Description Languages

Meta Architecting: Towered a New Generation of Architecture Description Languages Journal of Computer Science 1 (4): 454-460, 2005 ISSN 1549-3636 Science Publications, 2005 Meta Architecting: Towered a New Generation of Architecture Description Languages Adel Smeda, Tahar Khammaci and

More information

A STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN

A STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN A STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN GARJE RAKESH RAMESHRAO RESEARCH SCHOLAR, DEPT. OF COMPUTER SCIENCE CMJ UNIVERSITY, SHILLONG, MEGHALAYA INTRODUCTION Object-oriented Analysis and Design is

More information

Coordination Patterns

Coordination Patterns Coordination Patterns 1. Coordination Patterns Design Patterns and their relevance for Coordination Oscar Nierstrasz Software Composition Group Institut für Informatik (IAM) Universität Bern oscar@iam.unibe.ch

More information

A Usability and Accessibility Oriented Development Process *

A Usability and Accessibility Oriented Development Process * A Usability and Accessibility Oriented Development Process * María Dolores Lozano, Francisco Montero, Pascual González Computer Science Department Laboratory of User Interaction and Software Engineering

More information

Scenario-based Assessment of Software Architecture Usability

Scenario-based Assessment of Software Architecture Usability Scenario-based Assessment of Software Architecture Usability Eelke Folmer, Jilles van Gurp, Jan Bosch Department of Mathematics and Computing Science University of Groningen, PO Box 800, 9700 AV the Netherlands

More information

Checking consistency between architectural models using SPIN

Checking consistency between architectural models using SPIN ing consistency between architectural models using SPIN Paola Inverardi & Henry Muccini & Patrizio Pelliccione Dipartimento di Matematica Universitá dell Aquila - Via Vetoio, 1 67100 L Aquila, Italy finverard,

More information

Viale Sarca, Milano, Italy

Viale Sarca, Milano, Italy Defining Software Architectures Software Architecture course version February 2014 DRAFT V1 Francesco Tisato 1 and Diego Bernini 1 {tisato, bernini}@disco.unimib.it 1 DISCo, Università degli Studi di Milano

More information

Towards Decision Centric Repository of Architectural Knowledge

Towards Decision Centric Repository of Architectural Knowledge Towards Decision Centric Repository of Architectural Knowledge Bartosz Michalik and Jerzy Nawrocki Poznan University of Technology, Institute of Computing Science, ul. Piotrowo 2, 60-965 Poznań, Poland

More information

UML-Based Conceptual Modeling of Pattern-Bases

UML-Based Conceptual Modeling of Pattern-Bases UML-Based Conceptual Modeling of Pattern-Bases Stefano Rizzi DEIS - University of Bologna Viale Risorgimento, 2 40136 Bologna - Italy srizzi@deis.unibo.it Abstract. The concept of pattern, meant as an

More information

Components Based Design and Development. Unit 3: Software Design Quick Overview

Components Based Design and Development. Unit 3: Software Design Quick Overview Components Based Design and Development Computer Engineering Studies Universidad Carlos III de Madrid Unit 3: Software Design Quick Overview Juan Llorens Högskolan på Åland Finland / Universidad Carlos

More information

Aspect Design Pattern for Non Functional Requirements

Aspect Design Pattern for Non Functional Requirements Aspect Design Pattern for Non Functional Requirements FAZAL-E-AMIN¹, ANSAR SIDDIQ², HAFIZ FAROOQ AHMAD³ ¹ ²International Islamic University Islamabad, Pakistan ³NUST Institute of Information Technology,

More information

INTERACTION ARCHITECTURAL MODELING. Lecture 9 Interaction Architectureal Modeling

INTERACTION ARCHITECTURAL MODELING. Lecture 9 Interaction Architectureal Modeling User Centred Design 09 INTERACTION ARCHITECTURAL MODELING Lecture 9 Interaction Architectureal Modeling PREVIOUS LESSON(S) Synthetizing User Research Personas Actors / User Roles Scenarios Essential Use

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2002 Vol. 1, no. 4, September-October 2002 Requirements Engineering Donald G. Firesmith, Firesmith

More information

UNIT-I Introduction of Object Oriented Modeling

UNIT-I Introduction of Object Oriented Modeling UNIT-I Introduction of Object Oriented Modeling - Prasad Mahale Object Oriented Modeling and Reference Books: Design 1. Grady Booch, James Rumbaugh, Ivar Jacobson Unified Modeling Language User Guide,

More information

Design and Evolution of an Agent-Based CASE System for OOAD

Design and Evolution of an Agent-Based CASE System for OOAD Proceedings of ATS 2003 206 Design and Evolution of an -Based CASE System for OOAD Dong Liu, Kalaivani Subramaniam, Behrouz H. Far, and Armin Eberlein Department of Electrical and Computer Engineering

More information

Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards

Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards What to Architect? How to Architect? IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define

More information

An Introduction to Software Architecture

An Introduction to Software Architecture An Introduction to Software Architecture Software Engineering Design Lecture 11 Motivation for studying SW architecture As the size of SW systems increases, the algorithms and data structures of the computation

More information

Cliayter s. Vsing the ~usiness-it 5Ztfignment :Mode{

Cliayter s. Vsing the ~usiness-it 5Ztfignment :Mode{ Cliayter s. Vsing the ~usiness-it 5Ztfignment :Mode{ 5.1 INTRODUCTION The purpose of the previous chapter was to recognize the knowledge embedded in current alignment approaches by inductively creating

More information

COMP 6471 Software Design Methodologies

COMP 6471 Software Design Methodologies COMP 6471 Software Design Methodologies Fall 2011 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp6471-fall2011.html Week 7 Outline Software Architecture Layered Architecture Model-View-Control

More information

Architecture Viewpoint Template for ISO/IEC/IEEE 42010

Architecture Viewpoint Template for ISO/IEC/IEEE 42010 Architecture Viewpoint Template for ISO/IEC/IEEE 42010 Rich Hilliard r.hilliard@computer.org VERSION 2.1b Abstract This is a template for specifying architecture viewpoints in accordance with ISO/IEC/IEEE

More information

Architectural Design

Architectural Design Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN

More information

The Bizarre Truth! Automating the Automation. Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER

The Bizarre Truth! Automating the Automation. Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER The Bizarre Truth! Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER By Kimmo Nupponen 1 TABLE OF CONTENTS 1. The context Introduction 2. The approach Know the difference

More information

An Approach to Quality Achievement at the Architectural Level: AQUA

An Approach to Quality Achievement at the Architectural Level: AQUA An Approach to Quality Achievement at the Level: AQUA Heeseok Choi 1, Keunhyuk Yeom 2, Youhee Choi 3, and Mikyeong Moon 2 1 NTIS Organization, Korea Institute of Science and Technology Information Eoeun-dong

More information

An Introduction to Software Architecture

An Introduction to Software Architecture An Introduction to Software Architecture Software Requirements and Design CITS 4401 Lecture 11 Motivation for studying SW architecture As the size of SW systems increase, the algorithms and data structures

More information

What is a software architecture?

What is a software architecture? What is a software architecture? Peter Eeles, Senior IT Architect, IBM, 15 Feb 2006 There is no doubt that the world is becoming increasingly dependent on software. Software is an essential element of

More information

The Process of Software Architecting

The Process of Software Architecting IBM Software Group The Process of Software Architecting Peter Eeles Executive IT Architect IBM UK peter.eeles@uk.ibm.com 2009 IBM Corporation Agenda IBM Software Group Rational software Introduction Architecture,

More information

Ch 1: The Architecture Business Cycle

Ch 1: The Architecture Business Cycle Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures

More information

Frameworks Representations & Perspectives Position Paper Workshop on Language Support for Design Patterns and Frameworks, ECOOP 97

Frameworks Representations & Perspectives Position Paper Workshop on Language Support for Design Patterns and Frameworks, ECOOP 97 Frameworks Representations & Perspectives Position Paper Workshop on Language Support for Design Patterns and Frameworks, ECOOP 97 Palle Nowack Department of Computer Science, Aalborg University Fredrik

More information

Detecting Architecture Erosion by Design Decision of Architectural Pattern

Detecting Architecture Erosion by Design Decision of Architectural Pattern Detecting Architecture Erosion by Design Decision of Architectural Pattern Lei Zhang, Yanchun Sun*, Hui Song, Franck Chauvel, Hong Mei Institute of Software, School of Electronics Engineering and Computer

More information

Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms?

Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? CIS 8690 Enterprise Architectures Duane Truex, 2013 Cognitive Map of 8090

More information

MeDUSA Method for Designing UML2-based Embedded System Software Architectures

MeDUSA Method for Designing UML2-based Embedded System Software Architectures MeDUSA Method for Designing UML2-based Embedded System Software Architectures Alexander Nyßen 1, Horst Lichter 1, Jan Suchotzki 2, Lukas Kurmann 3 1 Introduction MeDUSA (Method for Designing UML2-based

More information