Full document describing all aspects of the curriculum, release 2 (pdf)

More documents

Recommendations

Info

ARCHITECTURE, DESIGN, AND PATTERNS (SE-C-03)AIMS:Software architecture is an active area with growing interest by researchers and practitioners fromthe disciplines of software engineering and software design. In the strict sense, softwarearchitecture is “a description of the subsystems and components of a software system and therelationships between them.”The increasing volatility of requirements and need to respond in timely fashion to changestaking place in the business or application domain, requires software design to produce systemsthat can be extended and modified relatively easily. There is an increasing need in industry forsoftware to support evolution of requirements, the rapid addition of services, and a wide variety ofcustomer needs.A number of architecture modelling notations and tools as well as architectural styles havebeen proposed to provide the foundation for developing robust, scalable, and reliable software.Explicit focus on architecture in conjunction with emerging best practices in analysis and design hasshown great potential to improve the current state-of-the-art in software product development.The course addresses this issue as a central design goal, and introduces the student to avariety of modelling and design techniques that address this need in the context of object-orientedsoftware development. The course covers all aspects of designing software: from architecturalissues (styles, patterns, views) to design patterns that can be described as “a common solution to acommon problem in a given context” on a lower lever of abstraction.LEARNING OUTCOMES:Upon successful completion of this module, the student will be able to:• clearly appreciate the impact of abstraction, modelling, architecture, and patterns in thedevelopment of a software product;• critically discuss and explore key concepts in software architectures, designs, and patterns;• critically discuss and explore architectural and design alternatives and be able to generatereasonable alternatives for a problem, and choose among them;• to recognize the appropriate pattern for a problem and to create an appropriate one;• apply practical skills to generate and deploy software architectures and designs based ontraceable requirements.SYLLABUS CONTENT:• Theory of software architecture.• Analogy with architecture in general.• Elements of software architecture: architectural styles (ABAS – Attribute Based ArchitecturalStyle); architectural patterns (event-based, layered, pipes & filters …); architecturaldescription languages.• Interaction between various types of requirements and architecture.• Master plans vs. piecemeal growths.• Architecture analysis and evaluation: SAAM (Software Architecture Analysis Model), scenariobasedevaluation.• Architecture process and organization.• Model driven development.• From architecture to design.• Reusing architectures.• Design patterns.• Framework and tools.PREREQUISITES: NoneRECOMMENDED ASSESMENT: Coursework and unseen paperhttp://perun.im.ns.ac.yu/msc-se/ 18
SOFTWARE TESTING (SE-C-04)AIMS:With the growing significance of computer systems within industry and wider society, techniquesthat assist in the production of reliable software are becoming increasingly important.The complexity of many computer systems requires the application of a battery of suchtechniques.Two of the most promising approaches are formal methods and software testing.Traditionally formal methods and software testing have been seen as rivals. Thus, they largelyfailed to inform one another and there was very little interaction between the two communities. Inrecent years, however, a new consensus has developed. Under this consensus, theseapproaches are seen as complementary. This has lead to work that explores ways in which theseapproaches complement.The use of a formal specification or model eliminates ambiguity and thus reduces thechance of errors being introduced during software development. Where a formal specificationexists, both the source code and the specification may be seen as formal objects that can beanalysed and manipulated. The use of a formal specification introduces the possibility of theformal and, potentially, automatic analysis of the relationship between the specification and thesource code. This is often assumed to take the form of a proof, but such a proof cannot guaranteeoperational correctness. For this reason, even where such a proof exists, it is important to applydynamic testing.Software testing is an important and, traditionally, extremely expensive part of thesoftware development process. Studies suggest that testing often forms in the order of fiftypercent of the total development cost. Where formal specifications and models exist, these maybe used as the basis for automating parts of the testing process. This may lead to more efficientand effective testing. It may thus transpire that the automation of parts of the software testingprocess is one of the most significant benefits of using a formal specification language. The linksbetween testing and formal methods do, however, go well beyond generating tests from a formalspecification.This module aims to introduce and critically analyse current techniques for softwaretesting, in particular the importance of formal methods towards this goal.LEARNING OUTCOMES:Upon successful completion of this module, the student will be able to:• critically evaluate the importance of software testing;• appreciate the need and usefulness of formal methods for the testing process;• develop an integrated approach for software testing and formal theories;• critically evaluate testing tools.SYLLABUS CONTENT:• Introduction to testing fundamentals.• Structural testing.• Functional testing.• Foundation for combining formal methods and testing.• Assertion based testing.• Model based formal methods.• Finite state machine based testing.• Testing from a process algebra.• Testing with UML's dynamic models.• Temporal logic, model checking and their role in testing.• Tools for automatic testing and continuous integration.• The management process of software testing.PREREQUISITES: NoneRECOMMENDED ASSESMENT: Coursework and unseen paperhttp://perun.im.ns.ac.yu/msc-se/ 19
Page 1 and 2: Joint MSc curriculum in software en
Page 3 and 4: 2. Goals of the Joint MSc curriculu
Page 5 and 6: 4. Module listList of induction lay
Page 7 and 8: 6. Quality assurance and controlQua
Page 9 and 10: • current practitioners with adeq
Page 11 and 12: 7. Module Templateshttp://perun.im.
Page 13 and 14: PRINCIPLES OF PROGRAMMING, CODING A
Page 15 and 16: SYSTEM MODELLING AND DESIGN (SE-IN-
Page 17: REQUIREMENTS ENGINEERING (SE-C-02)A
Page 21 and 22: INFORMATION SYSTEM DEVELOPMENT PROC
Page 23 and 24: SOFTWARE EVOLUTION (SE-O-01)AIMS:Wi
Page 25 and 26: FORMAL METHODS ENGINEERING (SE-O-03
Page 27 and 28: PRIVACY, ETHICS AND SOCIAL RESPONSI
Page 29 and 30: BUSINESS MODELLING (SE-O-07)AIMS:Th
Page 31 and 32: BUSINESS PROCESS RE-ENGINEERING (SE
Page 33 and 34: SOFTWARE ENGINEERING FOR DATABASE S
Page 35 and 36: PROJECTAIMS:This module is intended
Page 37 and 38: Moduleaka “course” or (in some
Page 39 and 40: The list of abbreviationsABASB2BB2C

Full document describing all aspects of the curriculum, release 2 (pdf)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?