FIT2005 Software analysis, design and architecture - Semester 2, 2011

This unit examines object-oriented systems modelling/design in greater depth than the prerequisite unit. The key disciplines of the Unified Process will be examined to set a context for analysis and design. Students will learn about static and dynamic modelling, and component-based design, using UML. Some common design patterns will be studied. Some topics about software architecture are examined.
The unit prepares students to be able to design large systems such as will be implemented in their final year project unit or after graduation.

Mode of Delivery

• Gippsland (Day)
• Gippsland (Off-campus)
• South Africa (Day)

Contact Hours

2 hrs lectures/wk, 2 hrs laboratories/wk

Workload

Students will be expected to spend a total of 12 hours per week during semester on this unit as follows:

For on-campus students:
Lectures: 2 hours per week
Tutorials/Lab Sessions: 2 hours per week per tutorial
and up to an additional 8 hours in some weeks for completing lab and project work, private study and revision.

Note: You must have completed all readings set for that week prior to attending the class.

Off-campus students generally do not attend lecture and tutorial sessions, however, you should plan to spend equivalent time working through the relevant resources and participating in discussion groups each week.

Unit Relationships

Prohibitions

GCO2813, GCO2816, GCO9806

Prerequisites

FIT1002 and FIT2001

Chief Examiner

Campus Lecturer

Academic Overview

Learning Objectives

At the completion of this unit students will:

• understand object-oriented concepts such as: association, aggregation and composition; polymorphism and generalisation; messaging and object interaction, state and lifespan of objects; encapsulation, connascence, domains, encumbrance, cohesion, coupling;
• know the finer details of syntax and semantics of the Unified Modelling Language with respect to modelling class diagrams, interaction diagrams, state machine diagrams, package diagrams, activity diagrams, deployment diagrams, timing diagrams, interface and component diagrams;
• be able to consider advanced topics in relation to use cases and specifications when analysing a system;
• understand the role of software architecture, and be able to employ several common architectural such as tiered computing, client/server, pipes and filters, P2P, Layered implementation, publisher/subscriber, to design systems;
• understand the role of patterns and pattern languages in designing systems, and be familiar with a range of structural, creational and behavioral patterns;
• be able to apply theoretical concepts and techniques for problem solving, to design complete software systems in a range of settings;
• be able to justify system design decisions with reference to a models quality, limitations, scope for future extension, and to theoretical concepts;
• utilise IT practitioner tools to support the process and documentation of systems design.
• be able to communicate the design of a system through electronic documents including UML models, other diagrams, and supporting text.
• have an awareness of the process by which object-oriented system analysis and design is performed using a framework such as the Unified Process.

Graduate Attributes

Assessment Summary

Examination (3 hours): 60%; In-semester assessment: 40%

Teaching Approach

• Lecture and tutorials or problem classes
  This teaching and learning approach provides facilitated learning, practical exploration and peer learning
  
  On-campus classes involve weekly lecture and tutorial classes. The purpose of lectures is to present new concepts, give some examples and discuss how the concepts relate to the examples. The purpose of tutorials is for you to gain practice and experience in applying the new concepts to different cases than were used in the lectures, and this should prepare you to be able to achieve the assignment work.
• Problem-based learning
  The assignments, and some of the tutorial tasks, are based on case studies/problems so as to situate the learning in a mock of real-world analysis and design situations, in a more controlled environment.
• Peer assisted learning
  The purpose of one assignment being a group assignment, is to further your skills in working with other people, in increasing your communication skills in team-based settings, and also for you to gain new perspectives on the unit content by discussing issues with the others in your group, so that you may collectively come to a greater understanding than if you had worked in isolation.

Feedback

Our feedback to You

• Informal feedback on progress in labs/tutes
• Graded assignments with comments
• Solutions to tutes, labs and assignments
• Other: Responses to postings made in the discussion-forums.

Your feedback to Us

Previous Student Evaluations of this unit

Recommended Resources

Visual Paradigm for UML Standard Edition - available from http://www.visual-paradigm.com/download/vpuml.jsp

Monash will supply you with the licence key for the Build number: 20110623 (which is version 5.2 of the Visual Paradigm suite; or version 8.2 Enterprise Edition)

This unit is participating in the Moodle 2 Pilot, Monash University's new Virtual Learning Environment. The direct-access URL to log in is: http://moodle.vle.monash.edu/

Examination material or equipment

pens, or pencils and erasers.

Unit Schedule

*Unit Schedule details will be maintained and communicated to you via your MUSO (Blackboard or Moodle) learning system.

Assessment Requirements

Assessment Policy

Assessment Tasks

Participation

The first assignment is a group assignment. Groups will be formed by the unit lecturers. However, groups of students who wish to work together may propose their grouping to the lecturer, who will make the final decision. Groups will be finalized by the Friday concluding week 2 of semester.

At the conclusion of the group assignment, you will be asked to perform a (private) peer evaluation of the participation/contribution made by the other members of the group. The evaluation of you by your peers can affect the part of the marks which is attributed for group assessment. It will not affect the part of the marks which is attributed for the individual assessment. The staff member is the one who determines how many marks the group-part is nominally to receive, the evaluation by group members has the effect of possibly moderating the amount, so that a student who is considered by the rest of the group to have had little contribution would not get as much from the group-part of marks as ther rest of the group gets. The full procedure is detailed in the assignment specification.

• Assessment task 1

  Title:

  Assignment 1

  Description:

  This will be a group assignment. However, students will be assessed on their individual contributions.
  
  The assignment asks you to complete tasks which allow you to demonstrate your ability to consider a business scenario to identify the requirements of a system, and to develop use cases and an initial class model of the business operational setting. Focuses on objectives arising primarily from modules 2 through 5.
  
  You are expected to work on this group assignment over the course of many weeks. There are items which must be submitted along the way. Very early (in week 4) you must submit 'questions for the client'. Additionally, at the end of each week from week 2 until the group submits the completed assignment, you are required to submit a personal weekly progress report.

  Weighting:

  20% of final unit mark (1/4 shared by all members of group based on quality of whole work, 3/4 from individual contributions based on demonstrated skill)

  Criteria for assessment:

  A detailed set of marking criteria including explanation of its meaning, will be provided with the assignment specification. As a guide, these are a broad description of the criteria:

  1. Ability to perform the activities involved in analysing and specifying a software system
  2. The degree to which the needs of the client are met by the final system specification.
  3. Ability to use a range of notations to express the specification.
  4. Your ability to work as a member of a team of software analysts including use of tools for communication and presentation of final work.

  Due date:

  Final work due by 11 September, 11:59pm; Initial smaller task (questions for client) is due by 15 August, and weekly progress reports are due on Sundays)

  Remarks:

  Failure to submit the weekly progress reports could lead to the lecturer contacting a student to ascertain their progress in learning.

• Assessment task 2

  Title:

  Assignment 2

  Description:

  This is an individual assignment.
  
  This assignment asks you to complete tasks which will allow you to demonstrate your abilities with regards to the skills and understanding presented primarily in modules 6 through 9, with greater emphasis being placed on the later modules. In particular: development of state machines;  development of polymorphic interactions between objects; and advanced modelling of internal class organisation.

  Weighting:

  20%

  Criteria for assessment:

  A detailed set of marking criteria including explanation of its meaning, will be provided with the assignment specification. As a guide, these are a broad description of the criteria:

  1. Ability to perform the required activities involved in analysing and specifying this portion of a software system
  2. The degree to which the needs of the problem are met by the final work.
  3. Ability to correctly use the range of notations taught, to express the final work.
  4. Ability to ensure consistency between different models of parts of a system
  5. Ability to apply problem solving techniques to develop a system's design

  Due date:

  9 October, 11:59pm

Examinations

• Examination 1

  Weighting:

  60%

  Length:

  3 hours

  Type (open/closed book):

  Closed book

  Electronic devices allowed in the exam:

  None

Assignment submission

Extensions and penalties

Returning assignments

Other Information

Policies

Student services