ITM305 Final Exam - System Analysis and Design

ITM305 Final Exam - System Analysis and Design (Toronto Metropolitan University)

• System Sequence Diagram (SSD): Shows the interaction between an actor and the system for one use case scenario.
• The system is represented as a black box.
• Initiating actors are depicted.
• External systems sending messages to the system are shown.
• Message sequence within the system is detailed.
• Special cases for sequences are noted.
• Actor and one object are shown.
• Object represents the entire system.
• Input and output message requirements are demonstrated.
• Actor, System, and Object lifelines are focused on.
• Message content and structure are emphasized.
• Repeated or alternative messages are identified.

Message Formats in SSD

• UML format for messages: Message name followed by (parentheses) parameter list.
• All message names start with a lowercase letter.
• No spaces in names; uppercase letters separate words within names.
• Parameter list items are separated by commas.
• Empty parentheses are used if no parameters exist.

Outgoing Messages (System Outputs)

• System's response to complete an event.
• Messages from the system to other systems requiring action and a reply.
• Each output is derived from input and stored data.

Message Notation

• [true/false condition]: a message-name and parameter-list. The asterisk (*) signifies repetition/looping. Brackets indicate true/false conditions for message evaluation.
• Message name (verb-noun) describes the service requested.
• Parameter list shows data passed with the message (parentheses for initiating messages, no parentheses for return messages.)
• Return value is the data returned from destination object to the source.

System Events and System Operations

• System operations are the operations accessible in a black-box component.
• They're high-level operations triggered by system or external events.
• System behavior analysis assigns system operations to conceptual class system.

Extending and Integrating Requirements Models

• Use case diagram, use case descriptions, activity diagram, system sequence diagram, and domain class diagram.

Steps of Object-Oriented Design

• Process of identifying classes, methods and messages needed for a use case.
• Design is use-case driven.

Design Class Diagrams

• Stereotypes categorize model elements.
• Persistent class: class whose objects remain after system shutdown.
• Entity class: identifier for a problem domain class (usually persistent).
• Boundary/View class: exists on a system's boundary (input window, web page).
• Controller class: mediates between boundary and entity classes.
• Data access class: handles database interactions.

Notation for Design Classes

• Attribute names use lower camel case notation.
• Type expression specifies data types like class/string/integer.
• Default values are indicated.

Method Signature

• Notations specify method invocation information, visibility (public/private), method name (verb-noun), parameters, and return type.
• Visibility ( + / - ) indicates access to the method (other objects).

Class-level Methods/Attributes

• Class-level methods apply to the class rather than instances (static methods).
• Class-level attributes apply to the class rather than objects (static attributes).

Fundamental Design Principles

• Object Responsibility Principle - Objects are accountable for system tasks.
• "Knowing" and "doing" functionality.
• Separation of Concerns (responsibility).
• Protection from variations (separating parts of a system likely to change.)

Quantitative Measure of Coupling

• Measures how closely related classes are. Tightly/loosely coupled.
• High coupling - numerous connections between classes.
• Low coupling - fewer connections between classes is better.

Cohesion

• Measures the focus/unity within a class.
• High cohesion - class has consistent responsibilities.
• Low cohesion - inconsistent spread of responsibilities.

Encapsulation

• Bundles data and methods operating on data to limit complexity & improve robustness.

Inheritance

• Enables deriving classes from other classes (hierarchy) with shared attributes and methods.
• Simplifies development by avoiding redundancy.

Indirection

• Placing an intermediary class between two other classes.
• Decreases coupling, but maintain a link.
• Controllers and firewall examples.

Polymorphism

• Allows same method name with various implementations.
• Differentiated based on parameter sets.
• Useful for method flexibility and reuse.
• Constructors exemplify polymorphism.

Use Case Controller

• A switchboard between UI and domain layer classes.
• Reduces coupling and provides greater security.
• Can be combined for groups of related use cases.

Understanding Sequence Diagrams

• Lifeline shows lifetime and interaction points.
• Activation shows a method execution period.
• Messages indicate interactions with origin and destination.
• Return values are shown for method results.

OOD with Sequence Diagrams

• Choose a use case, create a first-cut UML sequence diagram, extend messages and refine the diagram, and update the diagram.

Guidelines for Sequence Diagrams

• Establish messages from input.
• Identify involved objects (origin/destination).
• Describe each message with conditions/parameters/return values.

Assumptions for Sequence Diagrams

• Perfectly functioning technology.
• No login or technical issues.
• Perfect solution is assumed.
• No exceptions expected.

Week 10: Fundamental Design Principles

• Protection from variations: Separating elements likely to change from those that won't.
• Multilayer sequence diagrams: Adding view and data layers for a clear picture of interactive flows.

Data Layer & Access

• Handles the data layer for reading/writing persistent objects.
• Data access method 1/2 to create and get data for persistent objects.

Package Diagrams

• Method to define formal packages like subsystems (formal).
• Identifying classes or packages for understanding (informal).
• Dependency relationships using dashed lines.

Three-Layer Design Implementation Issues

• View layer responsibilities- display forms, handle input, and forward data to the domain layer.

Week 11: Agile Development

• Agile philosophies and guidelines.
• Agile values: responding to change, individuals and interactions, working software.

Scrum Project Management

• Scrum is a time-constrained, mini-project approach for executing parts of a larger system using short, tightly controlled cycles

• The main components of a scrum project are: Product backlog, Product owner, Scrum master and Scrum team, scrum sprint