Summary 2-page Overview INFOMSO

MSO‌‌Midterm‌ ‌
‌

Waterfall‌‌method‌ ‌ 4. Negotiation‌‌(with‌‌client)‌ ‌ - Parameter‌‌visibility‌‌(method‌‌of‌‌A)‌ ‌
- 5‌‌consecutive‌‌phases:‌ ‌ - 6‌‌demands‌‌for‌‌good‌‌requirements‌ ‌ - Local‌‌visibility‌‌(B‌‌as‌‌local‌‌object)‌ ‌
1. Requirements‌‌analysis‌ ‌ - Correctness‌‌(capture‌‌client‌‌view)‌ ‌ - Global‌‌visibility‌ ‌
2. Design‌ ‌ - Consistency‌‌(no‌‌contradictions)‌ ‌
Facade‌ ‌
3. Coding‌‌and‌‌debugging‌ ‌ - Completeness‌‌(all‌‌scenarios)‌ ‌
- Provide‌‌a‌‌unified‌‌interface‌‌(API)‌ ‌to‌‌
4. Testing‌‌and‌‌verification‌ ‌ - Clarity‌‌(unambiguous)‌ ‌
a‌‌set‌‌of‌‌interfaces‌‌in‌‌a‌‌sub-system‌ ‌
5. Maintenance‌ ‌ - Realism‌ ‌
- Encapsulates‌‌original‌‌system,‌‌thus‌‌
- Unable‌‌to‌‌deal‌‌with‌‌change‌ ‌ - Verifiability‌‌(automatic‌‌testing)‌ ‌
easy‌‌to‌‌swap‌‌out‌‌or‌‌change‌‌(without‌‌
- Users‌‌involved‌‌late‌‌in‌‌project‌ ‌ - SMART‌‌requirements‌ ‌
client‌‌noticing)‌ ‌
Spiral‌‌model‌ ‌ Class‌‌diagram‌ ‌
Adapter‌ ‌
- Iterative‌‌waterfall,‌‌focus‌‌on‌‌risk‌ - Inheritance:‌‌A⇽B,‌‌A‌‌superclass‌‌of‌‌B‌ ‌
- Match‌‌an‌‌existing‌‌class‌‌beyond‌‌
- Aggregation:‌‌A⬦‌ー‌B,‌‌A‌‌has‌‌attrib‌‌B‌ ‌
Agile‌ ‌ your‌‌control‌‌to‌‌a‌‌particular‌‌interface‌ ‌
- Association:‌‌A→B,‌‌more‌‌general‌‌↑‌ ‌
- Agile‌‌vs‌‌UP:‌ ‌ - Contain‌‌existing‌‌class‌‌in‌‌your‌‌own‌‌
- Composition:‌‌A⬥‌ー‌B,‌‌B‌‌has‌‌no‌‌right‌‌
- Interactions‌‌vs‌‌processes‌ ‌ Adapter‌‌class‌‌with‌‌right‌‌interface‌‌
to‌‌exist‌‌on‌‌its‌‌own‌ ‌
- Prototypes‌‌vs‌‌documentation‌ ‌ and‌‌that‌‌calls‌‌existing‌‌methods‌ ‌
- Dependency:‌‌A⇢B,‌‌A‌‌uses‌‌B,‌‌
- Collaboration‌‌vs‌‌negotiation‌ ‌
change‌‌to‌‌A‌‌affects‌‌B‌ ‌ Strategy‌ ‌
- Embrace‌‌change‌‌vs‌‌clear‌‌plan‌ ‌
- Find‌‌what‌‌varies‌‌and‌‌encapsulate‌‌it‌‌
- No‌‌redundancy‌ ‌ Analysis‌ ‌
in‌‌abstract‌‌class,‌‌with‌‌subclasses‌‌
- Readability‌‌(e.g.‌‌good‌‌naming)‌ ‌ - Make‌‌domain‌‌model‌‌from‌‌reqrmnts‌ ‌
for‌‌variation‌ ‌
- Testability‌ ‌ - Capture‌‌user’s‌‌point‌‌of‌‌view‌ ‌
- Contain‌‌abstract‌‌in‌‌original‌‌class‌ ‌
- Model‌‌real‌‌world‌‌classes‌ ‌
Unified‌‌Process‌ ‌ - Separates‌‌selection‌‌of‌‌algorithm‌‌
- Validation‌‌similar‌‌to‌‌requirements‌ ‌
- Iterative‌‌‌(usable‌‌subset‌‌of‌‌system‌‌ from‌‌implementation‌ ‌
‌
after‌‌every‌‌iteration)‌ ‌ - Makes‌‌for‌‌easier‌‌testing‌ ‌
- Phases:‌ ‌ Design‌‌principles‌ ‌
Bridge‌ ‌
1. Inception‌ ‌ - Program‌‌to‌‌interface‌ ‌
- Find‌‌variation,‌‌encapsulate‌‌it‌ ‌ - Decouple‌‌set‌‌of‌‌implementations‌‌
2. Elaboration‌ ‌
- Aggregation‌‌over‌‌inheritance‌ ‌ from‌‌abstractions‌‌(objects‌‌using‌‌
3. Construction‌ ‌
them)‌ ‌
4. Transition‌ ‌
Design‌ ‌ - Two‌‌separate‌‌class‌‌hierarchies,‌‌with‌‌
- Engineering‌‌activities:‌ ‌
- Cohesion:‌‌related‌‌operations‌ ‌ a‌‌bridge‌‌between‌‌them‌ ‌
- Business‌‌modeling‌ ‌
‌‌
- Requirements‌‌engineering‌ ‌ - Coupling:‌‌related‌‌modules‌ ‌
- Analysis‌ ‌ - Data‌‌coupling‌‌(one‌‌method‌‌relies‌‌
- Design‌ ‌ on‌‌data‌‌from‌‌other‌‌method)‌ ‌
- Implementation‌ ‌ - Control‌‌“‌‌(one‌‌instructs‌‌other)‌ ‌
- Testing‌ ‌ - Global‌‌data‌‌“‌‌(global‌‌variable)‌ ‌
- Pathological‌‌coupling‌‌(exact‌‌imp)‌ ‌
Requirements‌ ‌
- 3‌‌perspectives‌‌on‌‌software‌‌dev‌ ‌
- FURPS+‌‌model:‌ ‌ - Conceptual‌‌(domain‌‌concepts)‌ ‌
- Functionality‌‌(features)‌ ‌
- Object‌‌set‌‌of‌‌responsibilities‌ ‌
- Usability‌‌(help/documentation)‌ ‌ - Specification‌‌(interfaces)‌ ‌
- Reliability‌‌(uptime/recovery)‌ ‌
- Object‌‌is‌‌set‌‌of‌‌methods‌ ‌
- Performance‌‌(response‌‌time)‌ ‌ - Implementation‌‌(coding)‌ ‌
- Supportability‌‌(adaptability)‌ ‌ - Object‌‌is‌‌code‌‌and‌‌data‌ ‌
- Sub-factors‌:‌ ‌
- GRASP‌‌(help‌‌assign‌‌responsibility)‌ ‌
- Implementation‌‌(lang‌‌..)‌ ‌ - Information‌‌expert‌ ‌
- Legal‌‌(licensing‌‌..)‌ ‌
- Creator‌‌(create‌‌instances)‌ ‌
- Interface‌‌(other‌‌systems)‌ ‌ - Loose‌‌coupling‌ ‌
- Requirements‌‌engineering:‌ ‌ - Strong‌‌cohesion‌ ‌
1. Elicitation‌‌(identifying)‌ ‌
- Controller‌‌(system‌‌events)‌ ‌
2. Specification‌‌(describing)‌ ‌ - Class‌‌A‌‌can‌‌access‌‌info‌‌in‌‌B‌‌with:‌ ‌
3. Verification/validation‌ ‌
- Attribute‌‌visibility‌‌(B‌‌attrib‌‌of‌‌A)‌ ‌

‌