Softwarové inženýrství pro staré psy
úvodní stránka | English | 22. října 2003
Softwarové inženýrství pro staré psy
(Program semináře)
Systém a jeho chování navenek
Co je to problém? Co je to úloha? Co je to zadání úlohy? (zavedení pojmu systém) Jak poznáváme problémy? Jak poznáváme svět? (odvaha k interakci s neznámem; co je pravda a jak se na to přijde; rozum jako nástroj ověřování a předpovídání)
Chování (užitečnost nekonzistentního chování; jak poznáme, že systém musí mít paměť?)
Jak modelovat chování, které vyžaduje paměť? (sekvenční automat) Jak z několika automatů složíme jeden, tak aby se choval stejně? (kompozice SA) Jak zvládnout příliš složité chování? (dekompozice SA)
Ke stažení: simulační modely (ZIPped excel, 53KB)
Architektura systému
Jak zvládnout příliš složitou strukturu? (subsystém, objekt) Jak se ztrácejí data? Jak se generují nesmysly? Jak může výpočet uváznout? Co proti tomu můžeme dělat? (synchronizace procesů, sdílení prostředků) Jak se objekty synchronizují a jak spolu komunikují? (Vazby a interakce: rodičovství, polymorfismus, vazba celek-část, dědičnost, třídy a instance, atributy a metody) Jak se vyhnout chybám a ještě si ušetřit práci? Dědit nebo skládat? (Složitější struktury agregované a dědičné, vzorová řešení, opakovaná použitelnost) Jak zamezit, aby se změny šířily systémem? (robustnost) V čem se systémy objektů podobají počítačovým sítím a jaké poučení z toho plyne?
Životní cyklus jako algoritmus
Co je to program? Co je to algoritmus? Jak vymodelujeme jakýkoli algoritmus? (Turingův stroj, Turingova teze) Vymodelujeme jakýkoli algoritmus objektově? (systémy konečných automatů a jejich síla)
Ke stažení: simulační modely (ZIPped excel, 24KB)
Implementace a verifikace
Jak zvládnout složitost programů? (od regulárního výrazu ke strukturovanému programu) Co takhle zkusit totéž se stavovými diagramy? Co je to stav? (strukturované stavové diagramy) Jak souvisí stav programu s příkazy? (vzorové struktury a jejich induktivní podmínky) Jak zjistíme, že v programu nejsou chyby? (důkaz správnosti strukturovaného programu podle Zohara Manny) Jak dosáhneme, aby v programu nebyly chyby? (konstrukce bezchybného programu podle Davida Griese) Jak implementovat abstraktní datový typ? (implementace podle axiomat. specifikace) Jak implementovat způsob užití, interakci, komunikační protokol? (implementace podle gramatiky; Jacksonovo programování a jeho síla; specifikace sémantiky) Jak zjistíme, že v programu jsou chyby? (integrace systému a její strategie; různé druhy testů; testovací příruby, scénáře a data)
Ke stažení: simulační modely (ZIPped excel, 27KB)
Metodika OOSE a RVA
Přehled metodiky Object-Oriented Software Engineering (podle Ivara Jacobsona) Co když včera bylo pozdě? (rychlý vývoj aplikací založený na OOSE) Příklady notace Unified Method (UML)
Viz více:
The article "Old Dogs and New Tricks" written by H. James Nelson, Deborah J. Armstrong, and Mehdi Ghods published in Communications of the ACM, October 2002 made me to reply.
Home | česky | October 22, 2003
Old Dogs' Software engineering
(Programme of a learning discussion class)
System and its external behavior
What is problem? What is task? What is specification? (introducing the notion of system) How can problems be recognized? How can the world be learned? (courage to interact with unknown reality; what is true and how is it found out; reason as an instrument of verification and prediction)
Behavior (usefulness of nonfunctional and inconsistent behavior; how can the fact be determined that a system has memory?)
How the behavior which requires memory can be modeled? (sequential machine) How several automata can be composed into single one, so that it behaves the same? How too complex behavior can be managed? (decomposition of sequential machine)
System architecture
How to manage too complex structure? (subsystem, object) How do data get lost? How nonsense can be generated? How can a computation get stuck? How can be it prevented? (synchronization of processes, sharing of resources) How do objects synchronize and how do they communicate with each other? (Associations and interaction: parent - child, polymorphism, aggregation, inheritance, classes and instances, attributes and methods) How to both avoid faults and save labour? Inherit or aggregate? (Complex structures with aggregation and inheritance, design patterns, reusability) How to prevent changes from spreading over system? (robustness) Why are object systems similar to computer networks and what lessons can be learned from that?
System lifecycle as an algorithm
What is program? What is algorithm? How any algorithm can be modeled? (Turing machine, Turing thesis) Can be any algorithm modeled in an object-oriented manner? (systems of finite state automata and their power)
Implementation and verification
How to manage software complexity? (from regular expression to structured program) How about doing the same with statecharts? What is state? (structured state-transition diagrams) What mutuality is between states and statements of a program? (patterns of program structures and their inductive conditions) How to prove that there are no faults in a program? (proof of structured program correctness according to Zohar Manna) How to achieve a program to be faultfree? (construction of faultfree program according to David Gries) How to implement an abstract data type? (implementation based on an axiomatic specification) How to implement use case, interaction, communication protocol? (implementation based on a grammar; Jackson structured programming and its power; specification of semantics) How can a program be found faulty? (system integration and its strategies; various kinds of tests; test stubs, scenarios and data)
OOSE and RAD methodologies
Methodological overview of Object-Oriented Software Engineering (according to Ivar Jacobson) What if time means more than money? (rapid application development based on OOSE) Examples of Unified Method (UML) notation
See more:
The article "Old Dogs and New Tricks" written by H. James Nelson, Deborah J. Armstrong, and Mehdi Ghods published in Communications of the ACM, October 2002 made me to reply.
Reply on "Old Dogs And New Tricks"
Od: Ivan Ryant [ryanti@acm.org]
Odesláno: 27. října 2002 4:11
Komu: nelson_j@cob.osu.edu;darmstrong@walton.uark.edu;mehdi.ghods@boeing.com
Kopie: crawfordd@acm.org
Předmět: Your article in CACM 45/10
Dear Madam, dear Sirs,
Your article "Old Dogs and New Tricks" in CACM 45/10 p.132-137 raised my interest, since I have done similar thing (see http://sweb.cz/ryant/olddogs.html#english) in 1995-1997 and have made similar experience like You. I would like to compare my experience with what You have written of, and hope, You are curious, too. It has been a discussion class for experienced professionals taking 30-50 hours. The attendants were system analysts, project managers, programmers as well as - beyond my intention - inspecting doctors from a health insurance company (who proved to be clever folk and good analysts). Although there is only a little demand for such course in my country (the Czech Republic, Europe), the attendants felt well satisfied both with contents as well as with the learning method.
Josef Brejník
in spring 1970
The method has been a kind of cooperative problem method that I learned in elementary school nearly 40 years ago at my teacher Josef Brejnik - thats why I call it the Brejnik's method. It is perfectly usable with children and the more with adults, who need to manifest their competency and are always ready to fight for prestige, which can change a standard frontal lecture into a quarrel - I even made a bitter experience, no matter that I was able to defend my position quite successfully. The core of the Brejnik's method is asking the RIGHT QUESTION and letting attendants generalizing their experience (they have experience!) This way, they discover a more general, object-oriented way of thinking and a new set of concepts, or mindset (as You call it). My only role has been to keep people on topic, thus I earned my "royal honorarium" quite easily...
We have had no big goals, just broadening old ways of thinking about software. No revolution, no hard struggle, no breaking of minds, just discovering chances to make things better. And, of course, we have created SHARED mindset in the organization, which has promised, it would be applied occasionally in the future. There has been no requirement in their organizations to stop the procedural paradigm and to start practising object oriented paradigm immediately. It is a difference between our and Your learning course.
You seem to consider object-oriented thinking to be something entirely else than the procedural one. You write of correct and wrong ways of programming. I don't think, there are right and wrong ways of programming, like there are not right or wrong ways of thinking. There are ways of programming that are good or bad, appropriate, misleading, tricky, conventional, straight, original, ways that I am capable or willing of, that do or do not contribute to the purpose. It seems, it is matter of purpose, why and how You define Your object-oriented "mindset". The pragmatics of Your mindset is specifically Yours. The pragmatics of my object-oriented mindset may be somewhat different. I accept, of course, common definitions, but my understanding of them stems from my education and experience and aims to purpose, or goal, in order to make sense. I can prove as exactly as reasonable, that every procedural concept is a special case of an object-oriented concept. Isn't a procedure a "thing that behaves"? Isn't a variable a "thing that behaves"? (it remembers!) Isn't a concurrent process a "thing that behaves"? It seems, my object-oriented mindset differs from the Yours, but I state, it is not simply wrong.
What are the roots of my way of programming? In 1974-1980 we learned in school algorithmization and structured programming in a manner, that has been mostly based on Niklaus Wirth's "Systematisches Programmieren" and on the ideas of fathers of algol and structured programming: Peter Naur, Edsger Dijkstra, Tony Hoare on one hand and may be Donald Knuth on the other hand. Later, we continued this way with theory of automata, discrete algebra and much later, I learned additionally something of logic, set theory, cybernetics and philosophical grounds of all that. Since 1980 we learned concurrent processes and their communication and synchronization in operating systems, networks and embedded systems. That is another paradigm, such systems can be even non-algorithmic (e.g. Manna's & Pnueli's "strange behavior"). And approximately in 1982 we learned modeling and simulation in Simula 67 - it is object-oriented paradigm. None of those paradigms was called either correct or wrong - the school taught me to synthesize them. In ca. 1988 got Turbo Pascal object-oriented and I also learned C++. That time, I decided to implement Modula-2 compiler in object-oriented manner: not only object-oriented generalization of the Modula language, but object-oriented design of the compiler itself. Every nonterminal symbol is designed as a class (there are classes for modules, statements, expressions etc). Instances construct each other during the syntax analysis, every object connects itself to other objects according to the semantics, and generates code. It is correct object-oriented approach according to Your point of view, isn't it? Never mind that the compiler is implemented in the non-OO C language, because I had not enough money that time to buy a C++ compiler (and no way to download any freeware). I spent one and half year writing the Modula compiler, we finished it with help of two friends in early 1991 and being not able to sell any single copy, all my savings got spent and my one-man enterprise faded out silently with no profit / no debts. I learned then methodology, especially the object-oriented, and in 1994 I attended Ivar Jacobson's tutorial on OOSE, where I learned how essential is robustness for object-oriented design and how the requirement of robustness changes both data modeling and procedural modeling into the object-oriented architecture. This idea has been easy to understand for me. Briefly said, I consider the object-oriented paradigm to be natural result of the evolution of more specific approaches to making software.
That's probably why we in the courses haven't met the cognitive interference, You mention. On the other hand, You proved the similar way like the ours one, as You describe it in Your schema of generalizing procedural thinking, developing object-oriented thinking and applying it to concrete programming, although our results are not so apparent as Yours. Nevertheless, I followed what the attendants said and chcecked, whether they could understand the object-oriented concepts in accord with definitions. I asked sets of simple questions at the end of every discussion in order to assess, whether the goals of the discussion were met. And we performed a final test, as well. So far my diagnostics. On the other hand, I always emphasized, the attendants are to create their own systems of concepts in their minds and for their utility, thus they don't need to agree with my system that I have presented to them.
Now, I develop the courses farther, with emphasis on formal methods in order to prevent faults in software, including nonalgorithmic systems like distributed or real-time systems (see http://sweb.cz/ryant/fafrpr.html#english). Currently, just a new introductory discussion class has been prepared and tested that focuses philosophical topics of software engineering: learning problems (gnoseology, or epistemology), modeling problems conceptually (ontology and behavior), information-matter-energy (measuring the order of things) and the concept of time, synchronization as well as the "real time" - see http://sweb.cz/ryant/besedy.html#english and download presentation. The project develops slowly because of low demand for courses like that and because of extremely low budget - I finance it from my limited savings.
Your way of teaching object-oriented programming is scarcely acceptable for me. I am afraid of several risks that the radical, mind-breaking approach raises. Do You wish the object-oriented paradigm to be internalized by Your students? If not, how effective is Your course then? If yes, what is the price for internalization? How many times can be the mind of the student (and personal identity, too - we speak of internalization!) swept out and filled with something else and how many students get schizophrenic because of such method? The methods like Yours may hurt people, I am afraid. Why must Your students wash all their concrete experience out of their brains and start from scratch? Are the long years of experience of no value? If not for the employer, isn't there any value for the student her/himself? Is trained monkey a good professional? How much experience one needs to get a professional? What personal qualities she/he should have in addition to skills? (see Peter Denning: "Career Redux" CACM, 45/9, September 2002) What character must Your student have, if she/he lets You to break her/his mind? Is only flexible character acceptable for You? - it is ethical problem! The most flexible character is no character - do You mean, that the professional should have no character? etc. - I know, these questions go to extreme, that (I hope) doesn't apply to Your courses, and I believe, all Your intentions are honest. Nonetheless Your article provokes such questions without offering any answers. I just feel a danger.
Copy of this message is sent to Ms. Crawford: would she consider any part of these remarks appropriate to be published e.g. in Forum, I agree.
Thank You for interesting reading.
Sincerely, Ivan Ryant